


Institutional Archive of the Naval Postgraduate School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1987-06 


Computer Aided Software Engineering 
(CASE)--environment issues. 


Frey, Wayne K. 


http://ndl.handle.net/10945/22684 


This publication is a work of the U.S. Government as defined in Title 17, United 
States Code, Section 101. Copyright protection is not available for this work in the 
United States. 


Downloaded from NPS Archive: Calhoun 


: Calhoun is the Naval Postgraduate School's public access digital repository for 
/ (8 D U DLEY research materials and institutional publications created by the NPS community. 
«ist : Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 


NY KNOX appointed — and published -- scholarly author. 

; | LIBRARY Dudley Knox Library / Naval Postgraduate School 

411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 





http://www.nps.edu/library 


ee” 


ver 




























































































































































































































































































































































































































































































































































































































































































































































= ran —— er ee, bn) bd eit | bp bee Seti he apd —— a ———e eo Pl te a eal 
We 9 7 1 s4 a ae OES SAITAMA. A CER ie RA AL ORM BREAD LIAM Ase Gaede & BR aaah RAs 1 _ ean ap aut-a veces 
a ae ie rroos C ad fad s weet sats PA BALD Lava wasd "yi te Adis SPREE R84 cB td Or BEM VA, &) As had 8. 2839860241 Oy CM B1E0 8M WO Breer, & msaiioneamanaeen aati 
eerus r a e ot te 4 Pans a8 8 ye el 4 dictinmas OMe B81) RAM Dodger: 8 GAO’ ards aon ose: a Rake ata. iO Ant! @ 00:8. Be Me py Fe 
"5 Geet? eee Bere hee ‘Ais SS teh WASH RI CIG he 1 A An 9-968 © Bede M MA ERER FSA ERG #1 Mune Ma oGAide PAG EE Pe COME AD M&M OFbEe: Byte ptmad apie ‘anon 
se a ‘ ee ee oe Ae VA we Dey HAA Me asathe BU OE AMO B5508 8 Me Bibles 40-4 00 SOE ole cep eM. Oi & 0440 Rat Se oaneg Ae a 
a a it 2 i te 4 '‘ aa@ 2 GA 184A = ary hs Le M019: % Oe P18e. OQ: Roe SIMA. BBO RGR SIO MR 8s Bem. Bs Oe Pe Oy at REED, OD 
eS a. ed La Are Osag A we Ba prep r 10s @ & hie OAS OER 2818 @: Ooms OAs Ore er Red 
y ie e ' “4 a ee | 4 ! N41664.8/ oh ING bo Re Gok AOKD LF An MMe BB BOK OB Me Oc8: Be OH. Met § tags eee Me Goan 
‘ F 5 PU ‘oe re@S3h- 2 CW ord 6 BBall es 6.08 OE Oe a er, es PEO COME O&A BRE RMS O'R2@ Qe has Ae 0020 dne eS ar ORT 
’ Wene As ie sas bet eee Or, YY eye Wet wee te ee? iWeb My de BEM. Ee RBM @ OO RAa A OAM RE RELA BA. UDR 6 400.208: & Oy Se Ete 
7 oe: ie 0 SS Ce ee es VT Ok Vie se aks he atk a es ee 4 ee eee re 
. cutee ar Miee 8 $e 2 She M2 Mt | RA Wass & 
: ° pe a ‘ a ee ee 49Q AEE Oo OR 
a toa . cs A ae ‘ * aia To) ee ea Aosta SD met 
: . ; Ve , r) ‘ a 1h y a @ bots Sp UleA God tte mt © tp Mtenrs & A 
.. ee (ey aa oF BSA VAS Wb def Al aPC ar ia.t 4.8 
e. Lae a8 G6 4 28'S pttcg ar | Cy as Ate Rh et Mea F488 tO. 8, " 
eae Woe ie « tr + ee fe fee BP utd, 8 SER t Al Seka kek 
; 4 = e wer ye a aie tuleeo st 22 @ 24! ts O'e.8 S64 Aad & 
; z . e 14 ie We t ae f has a ee tev 6.48 O54 MtarBere.6 +m Ras 
i Bibel nated yt oe ti 62 Ath @ 5 Cae UA CAE Mee 
= : ‘ Ut MAA es tk te awk tlhe Rett Oe Soa Mee! FF RD erg 
’ a Cy oe ot (ter 6-6 MF eveq 6 ast a 1440 cm & ghost 9 RO 6 & YsbBen ches 
. 8 ? 1 1 o@. 3 poe « we a.0 e'} ie ae ve ee ee 1 3 . © hidels 
: ' a 1 . oP Ay 4 Se o er nw Aca oa & + oy @Acmtia 4 ee i oe 2 oD » Cem &.40406-% 
' : 1 ‘ ’ oes teas a ts Mo RUE © ob peeks 6 se Om, bin by ® (0 ObES AAP, OS. 10 Aim, aoe, A18 ease a) Qr0mee. leeditedar >) Manta ten dseiiieted Dad apenas ramrtemambasiam sal = 
ng . . . oe ' 4 ae RABDAAS @ Or 4.4 @ APU O88 98 31a & Bee. tee vangetep sandparcl meee Cae tiaeha hatte SAels MA dub Donita 298! 5 RAMAN M. AeCetanm aes WATE aeesoone 
et . > 2 nS t a oe a aD Apt Mi 1F Bat 4s Os 18 01 BUPhseel ai tehen SAPD AAALL: BARSAD 611 Ree ROG RAREA LA EAER LB COLE 6@,Bs OM Be as, F659 D> 0 te MMe om yi IDEs9  RGE-a eV FED! 18 Ride DOA: Bed ety 
' , ‘ e “ ; tte 4 SHORTS 4% o's @ ow ofeee ASS ig err 218 2 MEE BG BM RDB BA a | gd BABIES BO AMUSE ROR BO Be OR, 8 MA OERPRAL I AAD AT OO BNR e Mie i Mee SS AG ATL A 
4 aes « 4 49 ff fee Sec'ate ta 6 tge.ges MATRi2, A Ad totlee af Bah DES Or Bases Roe. Mp Rid tage foes ae Ace MM, op onde Steed: 
Pi ‘ : > 74 F fa tn > Vim Keene a) TAGE Ree OM. O10 'R Med BEbIA AG Fa DLAs RD om ORngOe DORE AMM te Oe Mets: 
La SL sf q f 4ef@oa dae Ue i PIELER ® O69 @ 0 'O 48, eR, ade Bi heh Ms Ban: On hoy 058K, Roe O56 M48 Moh 
= ; ms Fee anode Seltanacies 1 a a $0 Gr keer ger Sip MiRO® FMW weal Are 41M BAS ODOM AE TC ATMO Brie aid BEd oe 
; 7 1 . Ce ee ey on oe “ «8 4 ATAL © 298 Ohm eB. oa me 4.6 . 
: . ee to ae ‘ oa P06 WARIO? 1.8 LD ieBA NO L8rM Bette m0. 
S ‘ "YU O,9¢e vk§nare 3 
‘i Picea rie eer i. a eee ae A k 5 zee Perey te oe a ee SS eee 
” ea = ' 2. te abot MORO 2 tay ORES § S18 OES, 60m, Oc Ret we aA, ar Oay, S. ae Rete 8 AE BM © 6e 008 ee 
' so 1 aos qh. 1 v4. a ' me a igu 4 ery eel ee ee oe ey, we A008 OA he 
A ; , A ne ' yee _ antes s 1 Rpt ogniea in CF a oshureae Ao Alltasrcera4at ‘in 
ci “ ee er @ o Resa Mes CRIs 6 4. Holl iseio hele @ 
UI J ae s ‘ 4 4 eu Taner tye 1.88 i Loree rt Yh Pema ae D Mem ©. 1G mates Os O Bat 804 SOP Us Bow Baldo Ris. ty Sunewewse 
. ' 2% os ies 3 rege yoy a's Bs ih eA ted Oo Rt 9ee ds B58 88 Rasen 100% @ carry BR HOUMA DIS 216. 41) 65-008. 41 41S Me & ©145R.S OR ON 
= e ‘ ee er er) A Saw tre aoa ® hottie 4 AOA LadadedeMeugny 
1 i ' u vas onurg hee « Bach oe fo meh OUR wt 
; : ee Ld ° 4 M Moh OF thw FTE? ON Re Etch BLS 6 Neer S 
Li ' at 1 ue 1 5 oe a - ‘le ep teae eS sole Yen Sms Or p odeptan pee, sen ute 
. ' . as e Db BU © et Pte Class \ ee Sd) ee eee ey tr ve ae carne Sane 
: i ate fet emia nets e We mae Bind emeses rr pieh ale: Mimi @sOin, Vemcone-e “aliponpaneadle taancastemen-ateearoua eta reaserais saae©, ol araens cevetraearenmaneeumeconn 
‘ " Pua a preg ne fa, OF em gr ESQAPAS Rel 608d 8 AR a AbR Mihlgrngerbute St, ter Ogg18 oe ioe ee ee tee oe Te oe ee ee ey 
ad vd ca eee ee Oa ke co Rae OMAN SLY Spb) aie Gav alain e:aiaLs.Bielh © Gielen scares orate Seas Bs NSS OU cea) OND Oo SRUas Nee mena ae tO. > NON SR GS San @+ Oe SiR ween teneee ar 
oo. e 1 ae 1 . oy eee 1841 BE Yt For 1 BO kw ED lotr tn @ mo DIMem Ol See Ty eae tT PT oye Oe i De Pee ee ee ed Ee 
te 1 4 Le vo r] «4 . Petite Val bie} Ree e#ere H © oe Bhan! SH) Qh eae 8 a Gia te POE TO, B Corme GeO aR es eRe 8 Om Hm et es Bolbem, Qos ee eee oe enn peas ta gee 
; ' ' J ' 1e¢ (8 Rae ’ Peumeerauge @ e 68 at ve es 1B Rae 4B rhe ea 1G Rehan nanagdeanes. 6 et Ale aed Oh dh, 0D e STS 6 © ODOR MA he SMe My Bo Oe athe HS 
‘ = a eran oun ' wD e 5 ba ate 6 eae 8 8459 4: 71m Ae@his Blase tes Spnen Ni gye he See te me so mee aot 
' id . as eae |," wee tt ormt Oeee ot At Ot BBs FACT MIO Os De B Edad Aicla Jonas gs MFASECG ie REM 0. OW 9a Aee Bo 04 OR Sree PaSRE 
' ' 1 Cr 1 re ates ee o 4 C7 RH s 11 a no se OW OFe Oe om SiO I eR O16 ORO Aw heer on ee 1 ee Rete Aaa econ Or AAO es eae) Uti NIRS ener eee 
. 1 ‘es @er 4 * 9a Ole Set & & om Yea 2 5 RMA Aled, Fol ast ereser Au, 2) RW ZOOM be hsm RUACEo vee B48 2) 2a. Be GH ea, 4) Leo peepee samen a 
= : ‘ ' . sy 1 e 1 .s ' ates ce ay "ou Wa 1 o's Pri Ser Ariwe tatAr ras se} WO eee eRR Ae puak i facea: 87978 Renened Se papper re eee Papel eos peer eae 
i e mela antue ite 2 ' . lesa" ACHTRsaL Pe atfee Vidoes minor: itr, pa ee a 
- ‘ ‘ : Gs a1 Ms wis SULA CO SON ie sora va aut s ur ataueence® ian vareracacess CAMO LORNE. GEE AR 2 ete Ao BORE OO ene oft mes 
. os 1 ‘see: Pe wort gp afe.s oaks PAgt Um NelBde me hase 
' so. , 2 seus 1 & e4n 9 whe eens se ah tn Re ooh OAR wee 
1 . % v1 oe * tealy ® o«¢ S-foook no age ae ee 
' te eie a ' s'e@at wel $@ 0 6 a Mea 8 SHbede re FO Mn 86D. May oy he NPR CY Ry Ms A Boas - 
. Some eA : Le LR # Aiea ew sewer mdr AEN ites No yO. 1 Vis iBO dS ARMM S BoM ms NA n As Relea hee MYA GPR 8 mA Oi he bor ha G © Be ATO eM O59si: BaSem, slept es etapa e oe to 
7 Se ae pee ie ee oe ; Piette DT te deg FPN ESERAMEIS 1 O6k) O1H NT RID Couctirt ALEN SY, Wie: dpa ah MEAT ig ORES HEI ON Bs CAngES) Arm [Ande AA EAG@Ns te! Mcloed docesmvan co Coe Steak. Glwes corsa 
x ' e ‘ . . ' rT s? A? *@ lbistiaue he «Baan ye eo Hy 
. a ‘ e 4 i a ry vs . Ul 6s ay etsy 85 Pia setae etye s ite % Stars cee Oe ae Mahi mPa eee eee eonstaesie mnie. Bp de PBN SIMIA ER NERA se BERET, w. Bo Oe SOR OV Oy Boe Bee aot Se we 
= Lope saas van 26 Me 8b tee te aphonraa ld of O00 ele 181 Rats M-me RO Gn Meme Pode G ine A, Rh Qa Al GH AArmeds Oman My OI ths ee om Grete Sep ter 
: os ' ts % of: 4 14 Ow a mrt hte earn! tah AT Vertadog, MORI himel OW Meme BOQ Lm 1m pers OM NESE Romy te tinh mats BeRe Ms Ona oee = 
paves 88 wR Meer Hone ngs rer eh tr Or 9/18 ULipas bt Meets Siem. tes me ABS SAGs Sree es Seo eee eee 
AA ees ee ene Tek 40 mht m@NaTeT gan: tl Aréay © @ (avie OR A af ates eee: S 6.4.3 : ey 
: ‘ eo @r eae ere @ ASPo Oats sem aad 4 fs a Be GeO bee Beh atpelwnn, mess Ee Re ha aa 664 othe 4 he Boake enh ods Bs Bam Don sR) ® Wi Setehene®, Mote rebel 
en . L er furs ste g wed te pte age bh aes 4 of gk RROD CRAP Huts Tete tei aem. as Rim G1 MaRe Tings ee Obs ReNy me Ae od feber eek s Sapa 
D s i HO me 8 ek Vote made 0 0 Vetraghaata’s ea mae Soh Age 62 a Gy poem evn eS HMGRTI OMA 0 nh Be SOOTHE Mal Moe. Ui te Ee Berke Bw ity Bete, be Semaine Rage 86 
1 1 ' . Awl os Sen oe etd Ot 6 me late C44 AS cy Sarerte Gi Aihotetan th & & & Ames fndart: eae PERE tppcodaped oe cog Grc ta 
v4 Cacia ae | ph rt Sm Rin 6 He ol | Oe Make Nincpegy vlag fe i htntensreM Seed + de 01053480 & Oy ME AR BEM Oey See hy H Sats Bowe nem ‘sincera reese 
e on 1 1 to 1 e as oe nm thee 1ty @ 20m wae are 0 Ww ee 1 mre td € Rage mee OG SH Oey Aa ie! Ome Rete 1A BOH GSO MAb § B18 6M Oe Rah ew ee = 
° ry a& te © ' a ae orm eae Ql & WY fe> ae oe re ee tetdn infor ge diss aul 2591 2M ape. ime. ye ny eg haem. "8, eA LIE tea aes er Mae om Me Mame es te ie Be Re es ee Ot 
uJ * see ' 5 et =e ee , MADEN Cet Lah eth LG Wt Oh Ome 18.9. Oat LO Reread mb a! hegen ces Gee Pmac Hi, ade 0p 6 Oey. Be Rens ped Rom Rgty. RIDA Hs hemserReteeen pote a 
Sarat ’ ‘ ol peeenes ' G § ttindeG om ett oe, ad RU wierd acusp mp dierm htt: ils le.e ep0002 dare ee rer. iain apts cs a 
xh ae UJ ' 1 Ln | ' 8 ace yee £4 legohes "ye tier 1 Gi OMe est PRNe sys B28 00sk Bema, < pel Reel ata er ~ ahoum 
: : art pe LC ee LY Be COT Se eee 0 FS OMICY SCI Stara Wie ee sds (hlaie’ata sine egheMbertnteeee ret asdyetpaseansers 8 ion, a0 Bey Seater bene rman 
ee ® * his pa sant J . * o° near ar ent Se Seb me pre at ome 2 ae 2 2 : ™" ag t Otte ym an _— Boge Kee F. 90d Hee: 
ms : Sn si Qie «© Hieleee poeee Matslidgiteser ee Se ee ee RACs Mes Ge Calne Wy Rees Ain eek ea ete ote iantal 
' 2 « a 2 ’ a? Py Car ta tate ie. ot gee Neccurs Bem. Miesslme sot Sen Be fio 84s Nay Briain ann mas WN rat AA, ieee 
VS. - . ¥ AVG Le mo : im S6L wiket,e “is Gs DOW 8: LAras ROM Serid SES Vi be ae tah =e Wen . hres Leppcbenbedetee 
° ' e . » ova "eta oa ee Role chu gt Cee cc etna paddle trathe ty Grater eae 
oe Ks * SR Re eee et oe B8Ontee top 4 © Stare ot hed acy Bede Satesem em cehs tuahine di lake even. ofs: on ©, Phakns 1 Dans pat memne te 
. ' es ; rae ae 1a ISLS SSRI eee Wer Gisedsa emarensaseherr dive toad yentaium QvEam Had eeite B/ mann otens A4erma mS Om 
Le gehts Pe Mee) ONCEO OCT Ses ene Ga rie ier aaa PEO Ge Ww OO ot Ar ReGE tag its Vi are 4S we eae IOS achat eae rear hy 
ae | -. ee 1 eee Cop @timbeee st paar AE atast alain ae rary caiees PRR Perr et ort nf © ale Gee omens? pl Fetal 
. = - r) , Paar 7 ‘ . : Bue wes 8 ow tk @ 6 Uh OK . i} pe eager ope. ete in —- 
. . 1 ' . . Le er | 1 .Y feo wea bheimce: ee Pe se eee t 2 tet banter F 
? + lke. CD Fess a t1e e S beer ¢6ervee ‘ evans Reanahoy kil yop melee ie ah | Sam Ny -Harsrchcne tapenade 
ss : ae chs : - err en atagat ford to dpe. 10 es 
f x se! mn - ‘o4 nae Pe 2 PW a 1 © jade pent, Aare | Ste Bee 
a b > s ¢ po 4 4 t * e i i) " ha) ere & : Atedng Bde oe dp 0. Srecsiiserk ae 
* * . a oe he Pare ite ees it ae cer erect BAM NE Ma OF, OL TE NE NOM Nem: Oiteinne 
ill ° . 14 at ee Oe ey a wer Metete DNAse bey Omer 12 168M ys bok: 06 REI com mel meee Mina 
ot Mies . : at . U a ' . 1 1 A 30 wee tm Ante A woo OAS ti 2 Die MFO eke weed oe 
' . € or eo. - ehton (mae eed 
7 5 - wo oe8 = te an) a | ae a 5 aa aN e ee Lee Cm heteg vei taarne oT agi enka ee eiepeteeanh eg 
. e * o rae 1 poe te 0 ie etre ec ew © ime Cos ged Arte waa’) bam te ee mw eanene Oe Seats aay 
« * « te ake 4 [east aan - sot ' oats ro e erkac aie ata OP iT eee a SBM tes emelinioge © in typ Bones 8 on, halt tr 
2 ee eh Set Rates P SPOS as 4 * PN Ag rete © 0 we be 0* "2 weep ore Divan rare, bo} Wi oso 0e ei EAA. td aad ncprapectar tater Ursa: MCAS 
te . 1 . Cr dente e ify «6 owe 1 ~ 28 @ #8 » s - “MILL 2 o4 4 Pees . .3 ; 
. ’ ° : WAC ch Sic echt oa ht oe a eteE Chan PCs lae Rees ee aimee! at TESA AM. ot cirehitan BA wie Rey eS ee 
q e ion weet 4 n e: 1 wee ’ yr a el ty at Wy SEA SCSI Ad, eo aioe oe Shree Lew Aedes 
. « . ° . - eS 6 Cmrsue 1 . Rthe eit Sinks y Pics Re omins te eR, a Le cere, eee ee ar aes — 
° ° oe i ' ° ° ad | enn . wo SE ay fib Oth 08S CE a el a lend rer eae nae ee 
. = e . ' nee se er ACSC a eoueton 4 . ee teing 5 fF FSS TRE ATM as CW Ree Taos 00s Saks ve un st NESE home ete ante! 
° a “1 1 oe ° oeoee 234d e 5 "1 pas aaron leer yee pamesoe Sergneret Steerer fox 
soe Ld . e 1 « ' 2 Le | eat . SSS od Yea te aa ve Sate ey Fn ee a 
> o a) we . oe . «© a oth oe aa) fa? @ nt rs my aa a a pereery | oy yee Be Sr ae aeons 
. ° s 64 ° ones ° i ed tee ee “aon BU rele Fel atk, : : foeeeees 
x ey a t , Bes : see eee ete ee $Sesa avers 
oe ee <r ats 1 woe ae tw et bea am bans $F 05 EPA P iEe- . 
ae - . <2 ze the ‘ ° wet rev erngs rtd 1 ee tie? et eer ery 2s neewers eee 
. os Se sees eg ey "6 f ewe wt as Joe's “ : 
ee “@ .* s 2 . ’ be te te ee oe na Sa eae 
4 ed ' ae t Pars wun 8a) S Lae 5 ae tag ie-ts “ 
a e ' ° 2 cy mei 'e ry ve . 18 Pi ae 4, mat Fo dt e— E 
Ld Ch! e . . rary . a’ tee 6 Gar ras td 
- . . rt . ACs eens . ; 5 ee*Bare ws : 
oe ‘ ¢- e 0 See © (6% eh § ee ' . ° "any oe ofy teks * i eee 2 a ethasnte 
Ce hes . 1 ° ° . o* . a 5 ‘ae << Pea 3G att oe Lai Sm RTO EES 0 Wan So: et See & aS 4 
— Sievers = . F os a a Ate Pon be Ca Sp Het Terre, ioe me ure =8- STE tose Sakae whi ene ~ ET 
. eo aes? 4° . . 1 utp asl tpcR) seeds Sogs & PRONE ESS 5 Se Shas Se ds mee eo =e om ee aR es ae Kea 
“a . . “ eaf oat ote: £S ee ete at 21s Ras, 5 > = ips tanker wi <ire eS rie ah eb 
’ ' 78 Le & ' . ' : Beth h eave P24 . vee name Saw en rune ar =. ag 8 ee, 
Por " a a Pai ry one FP “es oe aes q ae Dee 5 Sok ‘S a TaKAPE IRS oo ee” . Mle 2 Rie a ewes. = ~ : a <a 
: e * € ° oe Oe ace? 7a se neige BFe BSP SIN EE ROR aL: Aho Rowan ent «0 & » ot a pe 
2 %s os o fe wei a : Tao ea SITs War ah wel FG ce memes bts ne fe ee: 
1 4 be . . sf Seer ke MO) BLU KIE SRA NEL ee Ean femme oa ort, 
. ‘ . ° 2 ght 6 ry Vel G43 wee @5 of. Mfg ORE PGs we PKS Es oe €2.. FT bend 5 fs RS S 
: e tere . 8 ve . oe Ay ret on do ar 2 ial On UCAS ORs uh L BEA Sk Je Set 
a - noes * . payee 2°22 SEWEEE nia Ae Sua M6 BG ct Baca ete ar 
= : 2 ban CAL ce COM keting! = SE Sw MRR EL Sea set CMe atAn ol CEE EE  p- —Sole 
oe ' - Say ihe ASD ¢ i. oret'ds Mei ys SMV AE a SS METI te a ad a we 0 eA 
: ‘ wets teuds La ~ fat %4 rots a 
. si : - , : s 4h ot . oa 8 bem t wrele SEES %! ‘ , Pht shee Uru a Oe ete FS 
° . Cee et ae cd e@ os - «¢ . . es «©. e oe «fees AR MRE oA yas. Shs 
: ae . ' aie ' Pie wt ry Cr cc a ae eT a aet eae. OP 
. - . ‘ . ' Oise cies & > te T.an @ 104 “tigt eo ft WENAVR 2” OR EKOS FA lI 
se a 2 ee ae Le} ’ . ~ Tie ue re" % 
e 1? rar eee 1 t +4 i] Vo hte te 
¢ 
° 
e ' 
x 
° 2 x ies (Asie 
eof ’ : : ! : = hg it aac Er 
: H b whe pe . - of Js ‘ OV" "RP : B 
: . Ha a Arahat Ae Hs ot ba nt Net Pel et Pe aera | 
=e = te " “AGRE CLEMIRRC OMEN ROR SE aE PEL 
. 7 . np aes ER ATLA ecedh vl. ESE Fee eee ; 
’ at be _——<--= “ 
: ¢ Fhe te at +r 
: EC Sp OTE 78 gt ee ee HR“, eahos ae we 
eye eeeae te Poor ee alr ie PS eb? CSM PACE LEE CLL EE Getee cre: caw 
G4 sttets @ never Rit she Fa gt SR el RETA OS oF tay Ber sweet? nea Rete eee eke apd Cee Se ee ree SE 
5 Cee ies te ae ae ee ee as oe PE ete cy Clee et ip oe Pee Pie a! ge te fe mara parca Se errepre pi pee ae eerear: 
PR ee OS LGSSIZ, oS 9 S.8 8 RM pr tiges PERI S ETS eee Fe Paioct Cy tt G I = A ie 5S . 
Fete ate PRE NCES” C8 a Aa 19 8. OGRE MEE ESL OE PPS NS 2 ST viel Sibionk. 28 fork 
ro ; PRG ERE fy PO 8: poSTy int Ae te tte een m gerwe ef: 
' Wr, 9% vere . Megat het nee rel sata aeee Fee Soe CPS fa? errs 
. ia opto, Pa tuee seperate {2a se tweareia ta. or Ste ee eee ae, ee 
: f overdo ae Oe Fen AN Glas OkRs oa eae cae ELE ST Ee cen ce - 
o re 104 @987* gag cqt melee scere” 37> See ee oe et eee (eae n° Sewer "07 
Pes ° WENGE A Xe ae ese er 
2 ar 
. ' pos hs 34 
e oe 
* te ye Tee sth 
ea ‘= 
§ i -s¢ 
PORTERS 2 OSPR Le POY OLS AIOE ES OT yr =e 
327 8 eae i be fetal gol nae | lak ht toe ot toe tel eee te a 
‘ uraxence CML USO" Go Feel e> Certs eee CPE WO y 
1 on ee? <n en pe 
. oa Oe ee Ree ee ee ee 
: ; PP LL aera ait ee ee lee agen ghee 
agvler re i. - ree bo = ia 
; : . Z Basis fray bn Sr aeie ope LEAL OAR OIA SMEG EN OE SE ET me mee 
° ° 4 * Di fix BL Sot Ta OO CEPR PRE LD 
SPSL hey Fewer egetareeey es [eaene abe 
2 es ec ge atts ees B02? Se 
r : Fas pid Seens pts Sa aL Pals Lah 9 Bs 
A VteTr t Fok EAT EE BA BA to ot ERE hr Al 
- = 2 . y = 
. °@ Pee eee | 78 Me tad 3 peepee 7° Fo pee mage 
F bg, elbenke ect! 50 Pe or 
1 rons, oe Me ere eeue EP fe Rage 
; 4 i vw eres eee 
wet bese CPT PEN ESTEE Ce Cnty Pe EI EUR pee ee wy 
’ Ps FONE Gre aie He Span Pa Ag OM Teh pra ape ona eg arnas wee Borer woman mal a 
. vet . Aare er Ae Bw, 
i my pa * . Ted ok gh hese ati dell Siepiesn!s o 2e Baer al 
. . PY le Cara a ieee S5 et eee Sf Pease 
£ ee AU i tk a Crs port ene oe AO og rig SNS et Pye ee ee we ep 
toes ewe ete 5 ‘Sor 8° PONE aS ag" gh EF 80 F 8A GCE GON TAT APS 
w apes re, fe Ma bee I dba Sa Wend ASD : Ni eae aen piotene, Tuer Op en Te Oo 
= pra Per yee me art gem y abuses sg uns te g® ae Maye poyep - oT eal sal dade cde Lona ot 0, -aes pinata eae ae 
ae a au siete Ps 5 it 22 ' bay Vte Fe AP Ole PRITY ent ae (piqimeltiesqigepnrmete, © or eatl caret meee aces. wey UR Pome re 
4 wee rl @ a arse vt ‘ an . a he ord 14 | Bas = E d os =e 
, nh BTC Red na Reannn gea ie mht gee eel ote fog ceneE OT OO 2 OUR ELE Nae PAOLO = 
= ; Peeer #8 2? a DIA Og Bee gare i 4a 28 DCT gO ee Ve Ee OLA ING: coy = spe * 04 ee gee etd et ted ele 
ow Foose os The 8 a © ie oe | OE PER Ee Fog ge eee Dy SE Gh SPU CANS VERGE ree PEE OP ene BPE ES ewe crt tga og oe apr aemadngoet amp en, 
ere. Le ntact tee Gta g eae a nae Paap aaa eh poe reaped al eR Ce Pere nea ee eer 
° * eee te 8 OF OE 6 Fert, BONNIE E ET i ey A prm ats why pb A bel vet eM AL pes pbs 6B, <p rtd pnp Ra ge Mh lleple) eee pla 
. . er ' ] rs y a.1t4 9 44 Lee Mate ye BNO pe wigigt Ol OLee, wits: “4% a cl : . 
re “Pate “90.3 ¢e "4 Taeetent Ce Oy paacee grass gages = wie PLA eNTR CTD ee fe Pe? ee gH SETI se Qorpen or eee FS = 
‘ 5 ett eee Sg EB TE gt eo e payee ayy Lier dss eepegiare ppd pappeedt inal Te Torrens gee erp oe reere mi enpiereamis qiertcoom eo were Doce 
: 16 @ 2? ee . ee rr oc Ce Oe a ea ee ee ts ty ee aT repeats Saqetareh A Ox teem + re Sit yates gre eryErdeer aneteuges 
ee e . > oy Le te ee Le ae DP ee ee te Tie tT) Wy er? £° Gone or qian FS) RPO e- or yew aE BF Ear Cran tO egy PRM Pere pret rere 
i oer , phy Ye o, 70h a Weir gre 2 SPE en 18 ee FO BIE ED PE IN Rs 
St ad wth vf toe elle & inser 
ey i Ss wut # ¥—V Oe is oe 
. te vs on ¥ ye ieee, 
evi & yighe gs 
= te : ° oer PH fF ele Fie 8 4 ’ 
; ’ 1 . ‘ ? rv tyiwe uu e1gte 
bal fap Re! eget Mel 
, a fe oe Le NTE oak | : 
° Fe a e * ee et ° Oe eae a YU Oye ie wine Te : 
‘ ey : x 1 gts - wenger gs ; : : F we a Or 
. . : Sa 2 ee < tee se mereka 6 Pe el 8 WAI EE BIE NF re giee Ng fiereEECTT Rm Eee grit wsequns eee 
cee foe ‘4 ogy 4 SR a) CU pone Otc ‘ * FW" wi be be ia etesi - Po what BBC pitcgdlivdai:tet ilodetoeeh Joh, sb ttre dep so dabble eats ik dah, nh. aplitenateihs, inaeatin 
. vata : 1 i eu 5 ref feb ht N eaerie wey hi dd mdethahteheen del. wh ah di steicbbhdihal naahexat dabtt aa? nfl . 
. . 1 te > wr ' ' 4 i] to 4 at Seh t 7 wy lend : ar Ae 8 = t eye areagay * erage doe 698 epee" ge Py 
' ' es eC Reo te UR it Awe 4 94g -8 oT 4 et 2th OY ILE yon Aan ee pry 1 es 9 TUE OE SLT ECT A IryY & eieny-< em nes we erense parapy 
<<? ' ' “a fet ' TL ON ted yee vie u -- 
? ° . ry . + of 8 my ( ae 44" o1 BE Gey & pry des et aoa 
e- ele . ' . are ae rae - ; cm wy 84 ay FRE hamindetinnal 
. 6 pe . ater rer? - On SHR eg i WAIST Wa 
° e e ce a,’ 8 oe em igs as . sy 24 ’ ry 
. vo ' ‘ ‘ vs ea erro t wu 8 OE Gg ag f Fee PF swy ya SW FE? Oo es ts BIE Cog? HWE yet ¥> 
te * ° ar 4 Fs 1a 4 8 v of P56 wie POS iwi CEPPY ETRY omens ev mgt 
* ¢ ’ F) « ee ae oe re Vv we you © Vesta 
ae 4% 4 we ' ' es ’ im 8 078 Pe froth 
ee . i ‘ a oe a tere ey, are 
ry ev + 2 a en er me Fi At hs Ee Yee byrne ttt wey 
Alevgenk a er ' ‘ mm stats fae CVA Pot see VRE forte 
' 1 ' bd ‘ Des . J Py f Le ee . Y Wv-“Gereee woes 
‘ ’ Lua +S ? PF ET yy EPA wat hie mage al 
. age $ . . te 1 a4 1 in ers ' § te 1 eee ome 
eae i ir t ‘@ ' dar teove pa bee er eee WML Pa ety 
tue egt . Jr ee | & ¢ Eben) © CC OR Hh) OE gers pena ke ea ers 
4 ' ' te oa. ie a + 8 ween cree ras hal ee ee a. 
° ae? 1e Lat yt A ’ . ie bal ‘ ene Visessury 4, IA 4 tj oer e & & COP 2 tee Ha Hor HR baht a 
‘ i a a oa Pag ae ace ° Pi tameew.: U ih Aaa An sarees poodtd4 Po A STOO SER WOE CONES 
. . te Ly 3 3 ; peuie © MPP git aed ag tut 2 i “cet thd rermer® : 
' > : ‘ : at o ‘< ' ‘ f » ry . 2 og ane A i eS ghee tine. orn CO otetay? gee OFIMs ela varheneoeye chan | eka : tieimecwery See = Meet. 
* . ° | . @ m. 8 ow ay pie ry ar) : WE POE RN EE a ge Oe 
t ee te ° . - te fe pe eas PRY aD gO TT tel yey PRE ne 1 flr ie lalla yh eel pid Bley % pose eaters ts Ph pla chn decal idan 
. . ’ * f te tees 4 : wer rat bs 0 CRITE GOON GENE He ots, BUG NCTE whivsste acct presdugrart: coweeaareeitaretaetramne oie 1 aieeaentier anere ae 
' ’ tes 41 8 7 8 ’ o -=4 wes . 5 we £ A 8 oat RPE VE SS Tet Cer De PR ERT BU Ae TE Teh vee ce arene eertaaanedenes sague uti vermnaravtaiuseeroco teenie axPreInaee am 
: “ as : “ We his we “ine 4, A 98 refer RpeVAAAR TUE FAL Geer ele — GWOT MPPE MEAGePeNt se Faue-veee boas tet at eho tat caer of o2 elt d on ohbh-ch oedihee oke 
é iy eu fe ‘ * Sao BA an ese 9 PF oe fma rey G99 Faved) Feet, ¥  Geyiergse Aes Va sirqb ore: Seen eras Pelee °F 2a 8 RTOS" CONN GO HET 
. : 4, Wis eRe » 4 iw a nd ot ‘s hs i ee eben heh hath ao lal es db tal Sel ltd A i RP STITH CTP 8° OF 
° ’ ° : c a te ' jes Hn AR. Be med 197 Ga Ret = “one ase? cans : PORE © eWEEK ew ee ME 
rs . ' 5 s ea? ' stung heytern 8 @ Fs fh! AACIEy? & & SW SewrE Pre $ / or nrwTee wwe 
s ‘ le aus ‘ , a sf 1ynry ss yore ete) ee ore otg: ft Ver To STON t Foren yest Cad re vo F HET GOGH YG! HPOV Le R IOI as dividend sinha fie! 3 Slept spin 
. . . § , é sce tsprer> 35 6 otk hOH seh ae yg OWN ag Wee Seb WHIT TEPAY 0) EC reek sal tho 18 eR RY Gaeariwtened eC ES VP a FEYOPES CPP wer capes 
. ‘ ‘ toh 2? » ¢F Pan STS Se Ee aa OR Posie ares eeu t toe fet Saat mck g od pice taser PEE PENA Wer 12 EWEN PLETE Sr Ere 
ne : : ae. ry grt ot eel 5! at Ae Tse eeninaye aera were gi ECU. eee ROR Or a! gaerete ema —EW 
: ‘ ot ' M4 . 8 pee 4 9 ae. sus LOH Teqe ry lH ty poem Tee Mm PC or ae niga ve dd 1 ac ; PTF weH Orers Br Rene 
' ‘ ; - t ed ~v,'4 big vv 44 41¢ sere oe boar te nopeet eles fPmerye we 
' t er Jee | ; ? $s ' te | 'e 7 teat) po rtpetyt ar nia 
1 . | 
e 


ee ENE M—ETF Tye 
9 Paw ewe 
L hd arte Be RAN ing P= be ES a8 Corea Teh Teer go Gr Gee CEI g /PRaTowr ee gorge re BF Te OUE ERE ORES Ug erer ag ge Vir rere 
e s ‘ 7c ae £7 nly : om any “ 2 , 
* 


‘and bt 680 


DUDLEY KNOX LIBRARY 
NAVAL PUS)GBLDULTE SOM 





Ts | 




















NAVAL POSTGRADUATE SCHOOL 


Monterey, California 





IME >> 


COMPUTER AIDED SOFTWARE ENGINEERING (CASE) 
ENV LRONMENT “ISSUES 


by 
WAYITE TK. Garey 


June 1987 


Thesis Advisor: Darrel. Davis 





Approved for public release; distribution is unlimited 


T233146 


NeclEl 
_ 





mmelass ified 
SECC AITY CLASSIFICATION OF Yrs PAGE 


REPORT DOCUMENTATION PAGE 


1g REPORT SECURITY CLASSIFICATION ‘oD RESTRICTIVE MARKINGS 
MameeeasS 1 Led 
ga SECUR TY CLASSIFICATION AUTHORITY 3 DISTRIBUTION/ AVAILABILITY OF REPORT 


Approved for public release; 


od DELL ASS F'CAT.ON - DOWNGRADING SCHEDULE distribution euiieited 


4 FERFORVMING ORGAN ZATION REPORT NUMBER(S) S$ MONITORING ORGANIZATION REPORT NUMBER(S) 


7a NAME OF MONITORING ORGANIZATION 


6o OFFICE SYMBOL 
(Uf epplicedie) 


pe 
& ADDRESS .C.ty State and ZIP Code) 7o ADORESS (City State and ZIP Code) 


Ba NAME OF PERFORMING ORGANIZATION 






Naval Postgraduate School Naval Postgraduate School 





Monterey, California 93945-5000 Memterey, California 93945-5000 


BH OFFICE SYMBOL 
Uf eppliceadle) 


Ba NAME OF FUNDING, SPONSORING 
ORGANIZATION 





9 PROCUREMENT INSTRUMENT IDENT FICATION MUMBER 








Bs ADDRESS (City State and LIP Code) 10 SOURCE OF FUNDING NUMBERS 


PROGRAM PRO,ECT TASK WORK CNIT 
ELEMENT NO NO NO ACCESS. ON NO 


MmeerPUTER AIDED SOFTWARE ENGINEERING (CASE) ENVIRONMENT ISSUES 


2 PERSONAL AUTHOR(S) 





ve 7 


-— vinctucge Securnty Classification) 


Frew wayne on. 


ee a RCO ORSE . Tome ME COVESEO 1@ QATE OF REPORT (Year Month Day) JS PAGE COUN’ 
Master's Thesis | tow 1987" June 


"6S SL FRPLENTEN TARY NOTATON 








18 SUB.ECT "ER*AS (Continue on reverse if necessary and identify Dy Block Number) 
Computer Aided Software Engineering (CASE) En- 
VenOmmleme, sOftware Engineering Environment; 
Pe nieve onment Develooment Principles 
3 AdS"RAC™ Continue On reverse if necessary end identify by block Number) 
The rising percentage of system costs attributed to software development 
and maintenance have resulted in the research by industry and academia 
MEPOmwd, 5 tO IMprove the productivity of software professionals in all 
phases of the software lifecycle. Computer Aided Software Engineering 
GxS—E) environmem@s are one SOlutiom Deine pursued. This thesis attempts 
Someot esc, [tOmM—mentoOUs cii@rts to date, some general principles for 
Pieimeci@trOnmcnts I onder tO assist decision makers who must procure 
Evem. this work 1s in Support of the Missile Software Branch, Naval 
meapone@eniter, China Lake, sG@alifornia (MSB), and their investigation of 
eee er oumentsmro improvemmnoauerivity. Problems of CASE development 
and use are discussed in this context. <A general problem solving approach 
Pitoucneabotidetren Or resouress 15 proposed with a focus on an individ- 
CeeeerOcTMemmomeGduGLIVItyY Subseteof a CASE environment. 


COSAT. CODES 
$uUB-GPOLP 





















4$°39L7 ON AVAILABILITY OF ABS”RACT 


Gl sclassieEOUNE MITEO () SAME aS Apr Mineilas Ss lt hed 
<c<@ aime one Oe RESPONS ace ROVIOLAL 


22D TELEPHONE (include Area Code) | e2c OFFCE SYMBOL 
Paote Wawel L. Davis fs ) 646-5091 Code »f Dv 


OOD FORM 1473, 84 MarR BI APRedton Tay be Used Unt exnausted SECURITY CLASSIFICATION OF "aS PACE 
Allotmer editions are oosolete : : 
Wie bass er bed 
il 


21 ABSTRACT SECURITY CLASSIFICATION 





CJ oric USERS 












Approved for public release; distribution is unlimited. 


Computer Aided Software Engineering (CASE) Environment Issues 


by 


Wavne KOE rey 
Lieutenant Commander/United States Navy 
B.S.(Business Administration), University of Minnesota, 1974 


Submitted in partial fulfillment of the 
reqnurcmentS lomthesdesrce of 


Mie [ERS@E SCIENCE IN GOMPUTER SCIENCE 


from the 


NAVAL POSTGRADUATE SCHOOL 
June 1987 


PbO RAC T 


The rising percentage of system costs attributed to software development and 
Pere NoMa a eeTesu fed uitmtie esearch Oy industry and academia into wavs to 
inprove the productivity of software professionais in all phases of the software life- 
Crome, COlmemer Aldea solar Encineering (CASE) environments are one solution 
Petes Ours at emt nesiseatremiaiat@: COclesce, iron various efforts to date, some 
general principles for such environments in order to assist decision makers who must 
procure them. This Work is in support of the Missile Software Branch, Naval Weapon 
Center, China Lake, California {MSB). and their investigation of CASE environments 
to improve productivitv. Problems of CASE development and use are discussed in this 
context. A general problem solving approach through abstraction of resources 1s 
proposed with a focus on an individual programmer productivity subset of a CASE 


envircnment. 


Gs 


ereSiSsDISCUAI ios 


The following trademarks are used throughout this thesis: 


e A\da® 


© Apple® 
e GEM® 
e IBM® 


e Macintosh 

e Macintosh I] 
* micro’ Aca 
© UNIX® 

e VAN 


is a Registered Trademark of the UiS. Goverment (Ada Jomn 
Program Office) 


is a Registered Trademark of Apple Computer Incorporated 
is a Registered Trademark of Digital Research 


is a Registered Trademark of International Business Machines 
Corporation 


is a Trademark of Apple Computer Incorporated 

is a Trademark of Apple Computer Incorporated 

is a Trademark of Digital Equipment Corporation 

is a Registered Trademark of Al&T Bell Laboratories 


is a Trademark of Digital Equipment Corporation 


Ue 


oe OFCONTENTS 


Cay 


ISTERED) EC ROUS cr 8 
BAG G.OU NPigmo ome ARE ENGINEERING AND 
NOY IRIS, SUE SSI og tS: Ce ah 10 
ee ees Ot ee Meme Oe ween Neer ROCESS . ooo. ec ee ee 10 
inter S Ol lV weeeeolecmenlwG PROBLEM ...........2.5. iS 
Li ERIE pak bo horno sa Po I 13 
J AOQUIBIOESIBS Ge v4 0 ot + 5 eRe ice en Le 
De NB VUGUN EOE esa 5 Soo ac ceed: 0 Sa i 
ie LASSER eo goo a) Some 17 
Ceo ey SLO meee TRONGENFT A SOLUTION............ 18 
jbo SIRE teal 12 eo vol CCO" Rhee cc: ee 18 
Vy eM UNESIORSUOTOL y ceo tals OA es 5 19 
So PT OVS OVATION JOE 6 oS re 2 
oe VELLORE ties eco OR eviIISSILE SOFTWARE 
BURA SCL SoG RSE OG Cl. tn US, 
Be} SBI SARIOUEE OU oh Oo 2 
i, ~MUSIOI . UR St ees ou oo de 20 
2, SRO yo EE fa Soc ote 0 geo soe 30 
5, NESSUS BNE SMe 5 ne 2S hy En 30 
3 CTech SmNieelaee eth . 0. jo. 6 sy elena 31 
S. (CAN SIE Dyes igsOl So) ole eee oc, o2 
Ce eer Onur Vi rROCeURE we NT) [ISSUES ........... 35 
eS ome emia Oho lae-onell mM PPrOdeGl ....¢yi...--.-++s0+4 93 
eee ceemne Ou otacasmell Bi aN DOTOdCM). 65...) ee ee ee 35 
5. MAGUIRE IG VOIRGBIC. 0. can gle) a olen 0) 86 cnn a 36 
CN TERS el OSS OPEB) O UII SENG Sf Ba eae 36 


IV. CASE ENVIRONMENT DEVELOP MIE NIMS Ses sy 
A. SCOPE OF CASE PROBL E \iS 2st neers 37 
l. Evolutionama@evciopment Politigally Necessan s.r a7 
2, Requirement 1 radeoits Comtribueima to silo heen 3§ 
B. FUNDAMENTAL PRINCIPLES ao RG se 
ENVIRONMENTS 26. ess. See eee ce ee oo 
|. Portable Reusable CASE Resources gee 
Joo Integrated CASE Res OUrCes germ nner ere ere 40 
3. Openvensvironmient:......’. .. cane nemem nee ntes cr: tccemrnnne nen eee 4] 
O Cser mendly ¢o.02%... xeed o <peeeeneenees, 4i- eee ee 4] 
CC) wBENCTIONAL ABSTRACTION AN ArPrROsCH fe 
SOLVING PROBLEMS i. .c Gege eee 42 
i. Delinition-of Abstraction “eee. ce ee 42 
2. Formal Specification . 23s). se 42 
3.. Abstraction of Physical Resounce: se. . pee (eee 43 
dee Abstraction.of Enmironmentesources = .07..2.... 2.00 43 
Bee OCA a Sk a oe ee eo 44 
6. Standards Enforcement vse emeetmacenient «4.000. een 45 
7. Top Down, of Bottomet p eeememmetrs oiys.c 07 eae eee 47 
My BWC TIOMAE REO | RIBMLE \ Sees le SIS 1SSises ). 2. ee 49 
Ae SCOPE OF THIS*EE POR year te 49 
B. [INDIVIDUAL PROG RAVE Teter RK Omee livin yates 
RESOURCES. fsecoek 22 a5 Wane ee ee rie 50 
1. . Physical Resources cise ee seers tre tere een re 
z. CASE Kesources: « 4. 3p gegen pemees crg cenr 50 
C; WHAT ABOUT THE READ pie oo. ee a7 
VI. CONCLUSIONS. << soap peat ne n> leer ce 58 
A. INVITATION FOR REY Ol GIO Ny gee Goan eee eee 38 
B. FUTURE WORK. cece meme oaenrmierer tne te, :iueree ce.) ) 20s 
C. RECOMMENDA TIONS BOR S38 emt. pon sene ene: eee 60 
1. Near Term: <i een eee ee eee 60 
2. The Future’ + ss.cesuteeegee screener eae eM nme esesrcs cae: 63 
LIST OF REFERENCES cg cso Goe nc ots oor een 65 
[INITIAL DISTRIBUTION LIES Tce ee reece cetera ee 68 


tv 


(2 


ty ty 


tJ — 


mis eOrrPiGl RES 


ee ater ae lodemorumematnrmne Wile CVCIGRS:....4 0.0.6 cee ee i. 
ie ee wine clsueenojece slipper Environment (IPSE),.............. 24 


Viee ieee Crd in eee ont environment (APSE) ...............-065 26 


I. INTRODUCTION 


Since its infancy. the software mdustry has worked to"lmprove the environmenr 
in Which people Work to create soltware. In general, tneseveionis were paccduan 
hardware developments andmby the way programmers thought about programming. 
The development of assembly and then higher level programming languages was an 
environmental improvement (over machine language) because they allowed 
programmers to think in more abstract, logical terms about the problems their 
pregrams were soiving. System operators and operating systems felicvcdmea. 
prograinmer from tne burden of managing hardware resources. The move from offline 
batch interaction to online real time interaction was another major improvement in the 
environment of programmers. As more and more software resources to improve the 
mrograinmers environment have been introduced, the hardware designers have provided 
the speed and computing power necessarv to support all of these features. and real 
work, without bringing svstems to their Knees. 

The hardware advances resuiting from VLS! and other technologies have allowed 
the proliferation of iow cost computers throughout modern society, resulting in an 
explosion in the demand for software. The drastic rmprovements already being made 
in software engineering methods have not kept up with this demand. 

For the past decade and more. tne software industry has expended much effort 
on the issues of soltware engineering as a methodology analogous to other engineering 
fie:ds. and to the development of automated tools and environments to support this 
methodology and enhance the productivity of software developers and maintainers. 

This thesis attempts to coalesce. from various software development environment 
efforts to date, some general principles for such environments to” aid the decisiam 
makers who must procure them. We begin by discussing the software engineering 
process. the software engineering problem and the issue of environments. We then 
consider a particular research and development software group, Missile Software 
Branch, Naval Weapon Center. China Lake. Ca. (MISB), their mission. their need for a 
Computer Aided Software Engineering Environment (CASE), and some of the issues 


~ 


they 12ce im pro Gunma @. ce. 


The concept of an integrated CASE has developed to include the cradle to grave 
lite cvele of software. We discuss the general state of technclogy of software 
development tools and environments to date and some of their problems. We discuss 
abstraction of environment resources and standardization of interfaces as potential 
PolUrors to Proolems. Narlimmi tae scope of this effort we focus on one of the better 
developed and uncerstood subsets of a CASE environment, the aspect of individual 
programmer produciivitv (IPP), in terms cf abstract resources applicable to anv C-ASE. 
ee she iG atems Goelecestecoiimendations. for Missile Software Branch 
fee eneesc Ol s adieu ebsscamin terns Of general CASE principles in the IPP 


CORICSE. 


WY. BACKGROUND OF SOFTWARE ENGINEERING AND 
ENVIRONMENTS 


A. THE SOFTWARE ENGINEERING PROCESS 

Seftware engineering has been defined in many ways, Boehm (1981, 2.16) called 
it “the application of science and mathematics by which the capabilities of computer 
equipment ure made useful to man via computer programs, procedures, and associated 
documentation.” The focus of such definitions is that software engineering is 
engineering in the same sense as the traditional engineering fields. 

It should be clear that we are not talking about one person progranmiming for his 
sole individual use. We are talking about the case where more than one ferson 1s 
involved in developing and'or using the software products. In general terms therovare 
at a munimum: a customer (an individual or organization(s) who want something useful 
done by a computer). a developer (an individual or organization(s) who must engineer 
the software to meet the customer’s need}, a user (Who may or may not be the same as 
the customer) and a maintainer (‘who mav or may not be the same as the developer). 

An applicable definition of process when referring to the software engineering 
process 1S. “, . . a series of actions or Operations conducine to an end) c:oaeee 
continuous operation or treatment esp. in manufacture... (tl ebsters, 1906, py iGree 
We take the “end” in the software engineering process to be an Operational Versicmees 
a software product including the object code and all attendant documentation (bcth 
histotical and deliverable) tequired tem egreanem: 

The common waterfall model of the software life cvcle, Figure 2-1 {Goeini ie 
p. 36}, with minor Variations, 1s often used to Capture the major (top leveljs Sseiiamom 
actions or cCperations’ in the software engineering process. This traditional view 
appears in the literature as far back aS a 1956 paper writtem by Flerbert D> Benn name 
describing work on the SAGE air defense sy stem soltwares Benmingtoum lS.) as 

The IEEE Ninth International Conference on Software Engineering, (20) vigieme 
2 April 1987, Monterev, California, LSA) met with the theme of “Formalizing and 
Automating the Software Process.” During the opening Plenary Session. Program 
Committee Co-chairman Robert Balzer stated that the traditional waterfail model of 
tne software engineering life evcle “is dead. Olir purpose here 1s ov to debatce: 3 


issue. However, this work is based on a belief that the waterfall model proves ee 
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known terminology and common framework around which much of software 
engineering to date can be discussed. We believe that the waterfall model represents a 
top level view of the software engineering process when the process is viewed staticaily. 
Such a static view is often attempted, and mav be appropriate, in dealing with svstems 
Where the problem and solution methods are well known and defined. 

When faced with uncertainty in the definition of the problem or methods of 
solution, understanding evolves throughout the software engineering process and a 
static view of the whole life cvcle is inappropriate, ve believe (nate ie sucheascasceume 
waterfall model is still useful, but not as the top levellof the processssimsveady miaien 
portions of it exist at a lower level of a process mich May be categoniz- (mes 
cvolutionary prototyping. In other words, a waterfall model applies at many levels of 
the overall software engineering life evcle process. [n our view Of such asdviamare 
process, a waterfall-like sequence of transformations may be executed repeatedly to 
“conduce” progressively more functional versions of the end product ssimecura- 
Waterfall mocel imposes no temporal constraints on its phases, an initial version mav 
be prototyped rapidly by manipulating not only the functionalitv of the prototype 
version. out the complexity and detail Of some phases of that version s life Cyvclomm. 
result can oe top down design, with a combination of top down and bottom up 
implementation, of a famtiv of evolutionary versions. Each new version is evolved bv 
extension of the collective analysis, design. implenientation and testing, ete, of some 
prior version. This approach can deal dynanucallv with problem solution uncertainty 
early in a project development life cvcle. as well as with continued evolution Giamaie 
project over tinte and in the context of technological advance. Lehman (133. 
Ciscusses, in detail, the dynamics of software evolution with respect to his now famuliar 
5S. P and E program classes. He also discusses the process of iterative transiomiamem 
tnrough waterfall like phases from topmost (1.e.. requirements) specification to final 
implementation {in this case a prototype or subsequent versions). Lehman's iterative 
transformation is based on a single canonical design step whereby the software engineer 
creatively chooses a formal lower level linguistic system in which to model the higher 
leve! model with which he begins each step. Formalism is itended 10) suneeuane 
mapping from the higher level model to the subsequent lower level model facilitating 
calculable (vs. empirical) verification, backtracking and change propogation activities 
which lead to iteration of the design step and support evolution. Such formalism ts not 


in conimon practical use in industry today. Such a process is intended to help avoid 


throwing out large portions of prior development work and having to start over from 
scratch. 

Speaking at the IEEE Ninth {nternational Conference on Software Engineering. 
rlerbert Bennington commented that the successful SAGE development efforts were 
Nome Givced were tie Wateriaeimwemmodeliilistrated in his 1956 paper. But. that a 
protcivping process, based on those activities, was emploved to deal dynamically with 
the uncertainty involved in the projects ambitions and possible solutions. So. these 
ideas are far from new. They have been studied and gained prominence in the context 
of past successes and failures. Given these views of the software engineering process, 


we can discuss briefly our view of the software engineering problem. 


B. THE SOFTWARE ENGINEERING PROBLEM 
The software engineering problem or crisis to use a popular cliche, has manifested 
itself in problems including quantity, quality. maintenance and management. 
1. Quality 
Software quaiity 1s a fundamental issue. Many products simply don't do what 
Roem ee gags Nae causes [or this Setterails reduce to the inherent difficulties with 
vaiidation, verification and testing. 
ad. balidation 
Validation is the process of determining the fitness of a software product 
fOr 1fS Operational mission. The developer interacts with the customer, at the start of 
the software engineering process. to translate the customer’s need into a requirement 
specification. Validation at this stage tries to deternune that the right product is being 
SWeieetcd. Maeecustomicr S cescription, Of waar the product must do, is inherently 


imprecise because it is expressed in a semantically imprecise natural language (e. 
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English). Within his own organization, the developer translates the requirements 
Gescription into a requirements specification. This has traditionally been the first step 
away from natural language toward a more precise representation. Validation of this 
translation 1s often complicated because the customer thinks in his natural language, 
Pp ee cClOpers Gepresemtation scheme. (Next, the developer translates the high !evet 
recuiremients specification into design specifications. Design specifies how the 
requirements will be met. The high levei requirements specification of whaz does not 
innerently contain all of the detail required to make explicit design decisions. Ideally, 
as questions arise, conscious effort would be made to revalidate the requirements 


specication with the customer so that the requirements specification answers the 


questions. Often this does not happen. Sometimes it is not even clear to the designer 
that his decision cannot be validated from the requirements. Additionally, design 
representation is generally so far removed from the customer’s view and understanding 
that an inherently imprecise reverse translation is required in order to get anv feedback 
from the customer at this point. After impiementation. validation must determine if 
the right product was actually built. As we'll discuss later, this last phase, testing. is an 
inherently imprecise process. 
b. Verification 

Verification assumes that the requirements specification is valid and tries to 
ensure that the product is built@correctly. The -developerminust transiave sce jem 
specifications into an implementation in object code for the target machine. Since 
design specifications are a more precise representation, this translation 1s much more 
direct. In fact. svstems have been implemented in which specifications are 
automatically translated from design languages to source code languages which are 
then translated into object code by compilers. tlowever, these procrams theniseres 
can not aS vel be proven correct, so empirical verification 1S essential to insuiemmme 
intent of the design is met by the object code. Por two decades, considerable eiionelnas 
been devoted to proving the correctness of programs (vemiieation). However, testme 
continues to be the best available tool for verification and validation. 

c. Lesting 

It is generally accepted that exhaustive testing (instrumented execution of a 
program, in its precise operational environment. over everv possible combinaiion of 
imiputs) 1s not feasible for other than trivial programs. It is also accepted that nothing 
short of exhaustive testing will infer program correctness. As Dijkstra said. “program 
esting can be used to show the presence of bugs, Gutmmever their absetices =. Dame 
1972. p. 6) So. the primary objective of testin@ becomes demoenstranions oc) stn 
programs operational readiness. Individual tests must be mapped from the design 
specifications for verification and from requirements specifications for validation. Since 
exhaustive testing cannot realistically be performed, a reasonable subset of all possible 
tests must be chosen. With knowledge of the design and code, (ov not simply treating 
modules and programs as “black boxes’) tests can be chosen for boundrv conditions, 
legal and illegal inputs, volume. etc. and iogical assumptions can be made about 
continuity of function between boundary conditions. Even if the program executes the 


tesis Without errors, and the logic is unflawed, operational readiness is only shown in 


the specific environment tested. Was some unforseen combination of inputs omitted? 
Is the target machine and its firmware and system software identical to tne test 
machine? 

2. Quantity 

Protiferation of computers throughout modern society has caused an explosion 
in dersand for software. This demand is a double edged sword. The more software 
ies the mere SOM imeminete i$ to be Midintained. A fixed number of software 
engineers, with fixed productivity, will eventually reach a point where ail of their effort 
1s consumed by maintenance. No new software can be developed until some software in 
Tamitemaree 1s retired, 

While the number of software engineers is not fixed, several industry studies 
conclude that the number is increasing too slowly to keep pace with increasing 
scitware demands. To complicate matters. the lifespan of existing software cften 
exceeds exmeetations: his is particularly true in the United States Department of 
Peleicem Wee here Capital investment in mulitarized hardware. logistics systems, 
training of technicians and operators, etc. all add up to practical and political inertia to 
xeep a working svstem in place (and in maintenance) long after technology passes it 
by. Improving the productivity of software engineers appears not only desirable. but 
essential, to stem the quantity probleni. 

a. Reuse 

The reuse issue is actually a component of the overall issue of improving 
productivity of software engineers. It is mentioned separately here because it has long 
been thought to be the key to making an order of magnitude improvment in software 
Production Capability. Since the earliest days software engineers have redesigned and 
eimiplemented things which had been built before. The problems of reuse are well 
known and go far bevondsany “not invented here’ esomania. Reusable code libraries 
achieved some early success for discrete functions (like mathematical formulas). It was 
hoped that higher order languages would make source code reuse a realitv for much 
mere complicated functions and programs. However. a general lack of discipline tn 
esiadlishing and adhering to language standards resulted in proliferation of subsets, 
supersets and generally inconsistant implementations of compilers for varving machines 
often defeating portability of such cede. Additionally. at the larger scope of more 
complex functions and procedures, the code is too detailed (1.e., data tvpes, data 


siructures, etc.) for easy reuse. As a result, it is generally the abstraction (e.g.. a 


domain specific model), and not the concrete implementation, that is reutilized. 
(Standish. 1984, p. 495) In general. even the reuse of the abstraction has been informal 
at best. Documentation of requirements and design specifications generally lacks 
standards outside a particular organization (and sometimes within). The way of 
particular cesign and implementation choices is often unclear in documentation. The 
level of effert required to understand what an existing design is doing and what, if 
anvihing, must oe done to: adapt it lo a new application Or mew emironimenn 15 Gien 
secon as more difficult than starting fresh. So, Gélise of the destraction ai .eme 
methods and tools to reduce the understanding Overhead? 1s Usually infer 
Individuais use their own prior work (things they understand and retain in their 
personal toolbox), out they reject organized library resources as too hard to use. this 
situation is changing as such methods and tools supporting reuse become more 
availzble, but formal reuse is still absent in many organizations. 
b. Productivity 

In classicai terms productivity can be defined as units of product delivered 
diviced by cost. Herein lies one of many problems associated “ith measuring ine 
procuctivity of software developers. There aré ao basic Wits Of software. [to uwemem 
various measures have been developed and attempts to instrument and study 
productivitv have been made. In general, we™ibelteve productivicy im some 
engineering activity has been worse than it 1S mow, We believe that various eflanismne 
improve the software engineering methodology and environment have improved 
productivity to its current level. And. we believe further improvements are possible. 
We doen't believe precise measumments of productivity are possible. 

Such measurements industry wide are complicated by the lack of 
meaningful measurement standards and the proprietary nature of statistics. Something 
as seemingly simple as lines of code per programmer per day cannot oe compared 
unless one Jefines precisely what a line of code 1s. Is it assembly code or a fourth 
generation language? Is their more than one statement per line? Bevond this ts the 
issue Of program complexity. Tlishl modularized*code is kel jo lave iioremiae. 
chan unstructured monolithic unmodularized code. Yet a poor design can vicld just as 
many or more lines of modularized code as a good design. Which represents more 
productivity? 

The most believaole claims for measuring software engineering productivity, 


and productivity increases, come from studies within individual organizations. At least 


they measure activitv in a relatively consistant environment (source system hardware 
and sotiware, source language. methodology, etc.), with consistant measurement units 
(whai is a line of code?) and with a relatively consistant group of individuals over the 
course of the study. With such a semblance of a controlled environment, the impact of 
introducing new tools or methods becomes more measurable. One consistant source of 
sue e Ol sion a eUnioer el .cars,mas ceen Boelim at TRW. (Boehm, 1981 and 1983) 
Cpeme ew iat Sinem restilimmor Sic eStudies can be generalized for other 
organizations. One cannot argue that such a generalization offers anv precision. But, 
It 1s evidence to offset the risk tn a decision to invest in similar tools and methods for 
producuvity improvement. 
3. Mfaintenance 
Soitware maintenance is commonly defined as any work on a software svstem 
after operational release. {It is often subdivided into maintenance to correct errors 
(corrective maintenance) or maintenance to improve or modify capability (sometimes 
Pave emer cel cmain.ceance).. In either case, maintenance involves changing the 
erogram. Without a complete understanding of how the program works and why the 
designers chose to make it work that way. a maintainer can often introduce totallv 
unexpecied errors. Such a change can invalidate all prior testing. Maintainers are 
Oe epeOewine OMlem 2) developers, aiid they musterely on the documientation of the 
Gey -opmicntorocess (or the unders:andine required to change a software system. 
eee See cree me ale (Oo Tepeat testing and compare results to original tests in order to 
ceternune the operational readiness of the new (maintained) version. They must 
conduct and document new tests to demonstrate readiness of new capabilities. Much 
Cc: development and maintenance documentation for existing software has been 
inadequate to support efficient maintenance efforts. Often. much of the development 
effor: must de repeated to do maintenance well. In reality, driven bv pressure to mect 
Operational deadlines, much maintenance results from efforts closer to trial and error. 
Needless to sav, documentation of such efferts, if anv, is seldom beneficial to follow-on 
maintenance. 
+. \[anagement 
\fanagement problems have been a major driving factor towards software 
engineering methodologies and tools. Problems such as; late delivery, over budget. 
unreliable sroduct. failure of product to meet specifications and product difficult and 


expensive tO maintain: are conunon. They are attributable in part to the quality. 
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quantity and maintenance issues aiready discussed. The famuliar phrase. “You can't 
manage what vou can’t measure.’, sums up part of managements woes. Another 
maior contributor to management problems is the chaos inflicted on static plans when 
the well detined problem or solution unexpectedly evolves into something else. Such 
attempts to manage, based on meastirement@ol thew esos nines ane (Urtien 
comipiicaced bv the phase inthe life eycle when thete@hange is discovered Chama. sean 
rrors involving the requirements and design, which are not discovered until late in the 
Geveloprmient process.jare often much more expensive ta Correct. “Wie can oleae man 
in discarding much of the werk already done. 

[n the last decade software engineering methodologies, tools and environments 
have exploded cn the market offering and delivering partial solutions to the software 


problem. Work and controversy surrounding development environments continues. 


C. DEVELOPMENT ENVIRONMENT A SOLUTION 
A software development environnient 15, im gemeral terms, the domain in wives 
the software system is developed. From the view of software engineers tlis domain 
consists of methods, tools (computer hardware and software) and other software 
engineers (the managers, analysts, designers. programmers, etc. wha make Upped 
engineering team). In other words. all of the resources necessary to engineer software. 
1. Structured Methodology 
Since the early 1970's, structured methods for managing and develope 
software have been Written about. taugnt and implemented. The structured methods 
support the major activities Cf ties waiter ail meeelTeicune 21). 
By structured methods we mean a collection of procedures and concepts to 
increase the productivity and effectiveness of the software engineering organization. 
Elements of the structured methods include: 


e structured analvsis, guidelines and graphical tools that allow replacing the 
traditional representations of the requirements specification with one that can 
De more easily understood. ow te cllsvamer, 


top-down design and implernentation: 


* structured design, guidelines and methods to help the designer distinguish 
between good and bad designs: 


¢ structured programming, composition of program logic from sequence, if-then- 
else anc do-while constructs with little or no use of the go-to. 


Associated with these methods are aids to implementation such as: 


¢ program librarians, to relieve programmers of clerical tasks and manage Version 
control and archival: 


¢ structured walkthroughs, peer group review of design and implementations to 
assist in error reduction and schedule pacing between formal inspections 


@reurdon, 1956. pp. 2-3) 

Controversy about thelvalue of these and other methods often centers around 
low much they improve productivity and effectiveness. As indicated earlier, how much 
is a dificult thing to measure and compare with anv precision. Yourdon savs “In 
general... thev double the productivity of the average programmer, increase the 
feweenity On Misecoue Oy -aipeorder Ol Macnitide, and decrease the difficultv of 
Inaintenance by a factor of two to ten.” (Yourdon, 1986, p. 3) We'll just say that 
common sense indicates these methods should improve productivity and effectiveness, 
and our general sense of reports from industry, regarding such methods, is that thev do 
work with substantial benefit. 

One of the serious problems encountered trying to use these methods is that a 
tremendous amount of cross referencing of data and data structures from one phase of 
the ufe cvcle to another 1s required. Also, many tasks are cychc in nature and require a 
lot of repetitive activity. For instance, validation of a data flow diagram representing a 
Pe (Uiiemiest espe cVicanoneameht require reiterating the diagram several times with 
yunor changes as the customer and developer narrow down exactly what the customer 
Wanis. Each namea piece of data on the diagram is a unique entity recorded in a data 
cictionary. Each new change to the diagram must be checked against the data 
SC Oiee Mic mwensmi: salle ites are Umiquely reccrded. Such repetitive or purelv 
(Mechanic d! tases tend tOmoe eIrOr prone and slow when done by humans. Thev are 
) 
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excellent candidates for automation using a computer. (MacLennan, 1983. p. 
2. Automation 
inere are generally three forms of automation supporting software 
engineering. 
a. Tools 
Tools are programs that perform a single type of function. A compiler, 
that generates object code for a target machine from source code in a specific language, 
is a tool, as are assemblers, linkers. editors. graphic tool boxes. spread sheet programs, 


Csr 
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b. Programming Support Environments 
Programming support environments are collections of tools to provide 

support for programming (normally considered the implementation phase of the life 
cvcle). They generally only directly support programmers. They may be a cooperative, 
interoperable set of tools (what we will call a toolset) specifically designed to work 
together with a common user interface and common data exchange formats. Or, they 
may be a set of disjoint tools which are separately executed, each with its own user 
interface. each performing its task on its own internal data structures, cemerally ame 
sequential file of characters as the only external data interface with each other. 

c. Computer Alded Software Engineering (CASE) Environments 

CASE environments are a relatively new concept. They are dan extensionvon 
programming support environments to the entire software engineering life cycle. Thev 
are intended to provide support to the entire engineering team (i.e., managers. analysts, 
designers. programmers, maintainers. etc.) for overall product development. 
3. The Environment Jungle 

We have been automating aspects of the environments in which we engineer 
software for a long time. At first there were simply collections of whatever software 
tools were available for the hardware and languages we wanted to use. In general 
nartly due to the large number of languages being developed, only the most basic tools 
were available (assemblers, linkers, loaders, compilers) to support production of object 
code. These environments Were based in batch processing techniques. As hardware 
advances produced teletype terrmnals for on-line real-time processing, environments 
gave the illusion {in the user interfacel.of being interaetive with the computenme a 
Was still sequential batch processing (for that user), only the batches were much 
smaller and turnaround time much faster. Video terminals evolved direct waigom 
teletype terminals, still processing lines Of Characters= Pine natural data Simuctiwenrae 
evolve for external interfaces in such environments were files of sequential characters. 
These are still the most common “standard” data exchange format industry wide. Since 
there are more than one standard’ Geharacten codes oc. 5) vam [ely ume aes 
programs are employed for portability of files. 

As hardware provided inexpensive speed and raw computing power, assisted 
by operatung svstems offering virtual memory support, a few languages began 
conunanding a large market share. As software engineers came to grips with the 


software problem. more complex interoperable toolsets appeared. These interoperable 


tools often rely on common data structures (other than simple sequential character 
files) representing objecrs which can be viewed and manipulated by various functions 
within each tool. These objects are normally stored in a database accessible by all of 
the interoperable tools. The database objects are generally onlv meaningful in the 
context of their tool or tool set which often miust eventualiy produce a sequential 
character file for manipulation by tools not integrated with the set. The advent of bit 
mapped graphic objects has added further complexity to portability of data among 
tocls. Due to storage overhead, and the complexity of handling bit images instead of 
Pte Oojects they represent. bit mapped sraphic objects are generaliv comipacted into 
unique, comiplex, proprietary storage code which constitutes a recording of the 
Scumerce © Tesource (tool) calls used to Consiruct the object. These recordings are 
Tepemeed and Cdiccdmim Order forecamsinuct Or inanipulate the objects. The storage 
format of such objects is therefore meaningless outside the context of the environment 
fegtured to replay it. 
a. Integrated vs. Disjoint Environments 
We use the term imregrated to describe environments with the following 

feacures: 

e¢ all resources conform to a consistant user interface: 

¢ ali resources are as highly interoperable as possible; 


WeeOCe isedma tein interrelationships are’ in a persistent common data forniat: 
which 1s meaningful to all environment resources; 


We use the term disjoint to describe environments which lack integration: 


¢ imconsistent user interface among resources requiring user to shift modes when 
nOia2 cOmyOme TesOurce TO anotner. 


¢ incompatable data formats among resources 
b. Environment Development Efforts 

The software crisis and technological advances (hardware. operating 
svstems, languages. user interfaces, databases, etc.) have resulted in a booming new 
ile@tn ee imeem iomments. Ve easily collected a full file drawer of documentation in the 
form of books, papers, technical reviews. promotional materials, and conference 
proceedings describing myriad environments under research, or in production or 
operation. What is generally most common about these environments 1s that they have 
so very lintie in common. 

(1) General State of Technology. Developing a CASE environment is itself 


a software engineering probiem of mammoth proportions. No standard requirements 


for a CASE environment have been adopted. Since the software engineering process 


itself is less than mature or stable, top down specification and design of an 
environment to model it has been deficient. For the most part a bottom up approach 
has prevailed. While many CASE labels have been hung on projects, at best it is 
lItmited integrated toolsets that are being made. [he CASE customer who can define 
his particular software engineering process is unlikely to find a toolset which is a 
complete CASE environment for his process. Since data portabilitv between 
independent tools and toolsets is generally limited to sequential character files, 
assembling a complete CASE environment from off-the shelf products can at best vield 
a disjoint environment. The majority of what are being called CASE environments 
today include: 

@ graphic tools supporting various structured analysis and design methods; 


e program design language (PDL) tools supporting prototyping through 
executable specifications; 


¢ programming support environments supporting specific !anguage 
implementations, debugging, documentation, version control, and archival: 


¢ project management systems supporting a varietv of management 
methodologies and economic models; 


e office automation toolsets: 


e hardware and software supporting multiple view window interfaces and 
multitasking. 


A prevailing point of view seems to be that it 1s unlikely that any single organization 


could, or should, define canonical requirements for some CASE environment and then 


implement all of the tegrated nesatrcesseam mstameiace it. 


‘This may not do justice to a few large software developers who have invested in 
long term top down cevelopment of environments for their own use based on their own 
software engineering process and methods of operation. However these svsiems are 
elther generally not availabie off the shelf. or represent an exorbitant investment. and 
complete integration within them 1s dubious. A possible exception , the RI00U Ada 
Development System from Rational (Mountain View, California), has been developed 
for the market place and is touted in the literature to epit@mizem eee 
integrated CASE environment.” (Suydam: 1987, p. 58) However, most would! clascme 
the R1UOO dedicated hardware architecture and software as an exorbitant investment. 
Also. we should note that European CASE environment efforts seem more advanced 
than our own domestic endeavors. ISTAR. from Imperial Software Technolcgy 
(London, England), is an example. ISTAR’s top down design provides for a flexible, 
open and exiensible environment. 
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a how 


[t is generally agreed that integration of tools toolsets (resources) is 
desirable within an environment for: 


em coherence, whereby all the tools behave in a uniform and consistant wav (e.g., a 
coimmon user interface stvle); 


* control, whereby tools behave in a disciphned way {eg., not allowing 
unintegrated tools to bypass and subvert a configuration management tool); 


eh io ene tool smmvene vocetner b. Sharing data (data is structured 
DIdepealencu Oo! (iee@el ww. wich create and Use it) 


eel yi et eke cum ecisic Coniict between the desire for integration and the 
Gesiree Neiced  eCOnOmicC imese Olumomar) [or Environments to accept tools from 
VamloucecOuUrees.. 9. € [ec] the most promisingme. the clrent approaches to resoiving 
Ps con er ?s vo ould around a kernel structure of resources which provide services to 
the tools for accessing and manipulating objects in a standardized environment 
cidvelp scm lce ie Ihteriaces: 10. ife-esnoumemmresources are derimed, tool developers 
Milo achere tO the interfaces will Cevelop imtegratable tools. Two such efforts currently 


Oo¢ce wedre tie Porable Common [ool Enwapenment (PCTE) which is the base for 


pS) 


Niel wer UrOpeim envionment and toolmempiects (including ISTAR. see Figure 2.2 
fe eer ole ofp, 27)) and the Common Apse(Ada Programming Suvport 
Eiarouiemt, Interiace Set (CATS) sponsoredm@ex the DoD. 

(2) United States Department of Defense (DoD) Initiatives. Early in the 
DoD common high-order language project which spawned Ada, developers recognized 
Cid stem iomaeceaiOie would be iysuflicient to combait the problems associated swith 
DOO sor teeerojecss. DoD spoirsored development of requirements, defining the 
oe OCmmiena Sueporl sem memment (APSE), with the stated objective “. . . to 
support the development and maintenance of Ada applications software throughcut its 
(ere eC Cm mmroeedictlar empnasis On SOitware for embedded computer applications. 
(Sronentan, 1980, p. 1) Fundamental concepts of the APSE included: 


* eeiostearcer en ironment, were the APSE 1s hosted on a development machine 
PMeeeetewrercctimacmime Of the soltware, to be developed utilizing the -\PSE. 

es c >) 

Giayees a cillerent machine: ~ 


ee program database, to include ail project information (e.g., source and object 
code, documentation. specifications, etc.), 


* extensibilitv. with all tools written in Ada. 


9 ; one : 
“In embedded svstems the target hardware may be so limited in resources (speed. 
memor., etc.) that it cannot practically support the development environment. 
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Figure 2.2 The ISTAR [nteerated Projcce Suipperminy meme ig le tele 





The original Stoneman representation of the APSE is illustrated in Figure 2.3 (Booch. 
eee eee nGstiiacmine Teseurces are provided through the Kernel APSE 
(KAPSE) which provides the logical to phvsical mapping. The Minimal APSE 
(M[TAPSE) contains some minimal toolset for program development, and the APSE 
overail represents a life cycle environment. 

While early Stoneman developers may have thought in terms of a single 
Organization developing an APSE or MAPSE under DoD sponsorship, this approach 
quickly ran into the integration versus independent developers conflict mentioned 
earlier. ? Commercial developers are competitively pushing the edge of technology in 
programming support and CASE environment resources. Anv standardized integrated 


toolset from a single developer faces stiff competition in fields (e.g., editors, debuggers, 


user interfaces, etc.) Where few widely accepted standards exist and several potential 
defacto standards might emerge. To encourage the competitive advance of 
environment technology in a direction supporting integrated environments, DoD 


sponsored the development of the Common APSE Interface Set (CAIS). 


The CATS provides interfaces for data storage and retrieval, data transmission to 
and from external devices. and activation of programs and control of their 
Peron mm imverccr (oO denicveuinilemimity im tile interfaces, a single model 1s used 
to consistently describe general data storage. devices and executing programs... 
referred to as the node model. (J\ilitary Standard Common APSE Interface Set 
el oe oe ll) 


The development of CAIS has been a lengthy and methodical process of bounded 
Scope, | he version Of the specification scheduled for release in the Spring of 1987 1s 
intenced to support some transportability interfaces often required by common 
software development tools, including: 

Smeine mede model; 

@ processes, covering program invocation and control; 

¢ input output, covering file and device I O and interprocess communication: 

? utilities, list operations for manipulation of parameters and attribute values. 


Some CAIS issues and decisions deferred for later versions of the CAIS include: 


"The Army, Navy Ada Language System (ALS) was such a venture from which 
the Army has now withdrawn support. The Navy has continued with ALS-N with the 
ssecific purpose of directiv supporting some major unique Navy embedded 
architectures. It has been anticipated that such support will not be spontaneous from 
Pepi iwate Sceven cule «o the e\tremiery limited vertical market. 
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The .A\da Programming Support Environment (APS). 


Conimand 


e configuration management. CAIS supports resources for configuration 
management but no specific methodology; 


e devices, supports scroll. page and form terminals and magnetic tape drives. 
(Gtiiemdeices Andsesssibeotier “No! or {SO interfaces (¢.g.. [SO DIS 7942 
Graphical Kernel System (GKS)) are under consideration); 


e inter-tool interfaces, are not defined: 


e interoperability, only a primitive text-oriented file transfer capability is provided 
between a CAIS implementation and its host. CAIS does not define external 
data formats for transfer between environments or between a host and target: 


e archiving. a decision on the form that archiving interfaces should take has been 
Gelerred 


(Sfilitary Standard Common APSE Interface Set (CALS), 1985, pp. 1-2). 

The Software Technology for Adaptable Reliable Svstems (STARS) 
DPmocwinemesraorsneas oy the WoW am late 1983 included the,» STARS Software 
Engineering Environment (STARS-SEE) task. The early objectives of STARS-SEE 
Were to specify the requirements for a complete life cycle environment which was fully 
integrated and interoperable, multilingual, utilized state of the art technology and was 
itself designed to evolve with technology. Early STARS leadership felt that the DoD 
itself was best capable of analvsis and definition of requirements for such an 
environment. A joint services teani composed of uniformed and DoD civilian software 
proiessionals, augmented by DoD contractors. analyzed the software engineering 
process, requirements for the STARS-SEE. and the state of technology. This resulted 
in generation of a five volume collection of thirty-five preliminary reports, by 1986, in 
preparation for defining the STARS-SEE software architecture. (Naval Ar 
Dee elem eenich slo soumomuisiealy Changes in» project management resulted, 
essenuallv, in disbanding the STARS-SEE task effort within DoD activities and shifting 
emphasis to encouragement and support of private sector software engineering 
environment devetopment efforts. 

In addition to such high level DoD environment initiatives as 
APSc CAIS and STARS. several lower level efforts exist. DoD field activities engaged 
in software engineering alreadv have an investment in their own unique individual 
environments which have evolved bottom up (with the evolution of hardware and 
soitware technology) as they have done their jobs over the years. They are in various 
stages of evolution from batch oriented and “interactive” time shared central 
mainframe. mini complexes, to networked “personal” nucrocomputers with “terminal” 


access to central computing resources. Individual initiatives to upgrade local 
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environments with relatively inexpensive “personal” computers and off-the-shelf 
software engineering tools in such a bottom up fashion are often seen as both blessing 
and curse. Blessing for their contribution to improving an often otherwise extremely 
unproductive working environmient, and curse because of the lack of interoperability. 
transportabilitv, consistancy, etc. which thev represent. * DoD Ada implementation 
policy (essentially that Ada is the only authorized programming language for new 
embedded svstems and existing svstems entering major revision) has been one point of 
focus for many of these independent efforts in DoD as well as for the tool and 


environment developers. 


*Not all of these efforts are so limited. Some are large and well organized and 
funded (e.g.. the Interactive Ada Workstation being developed under contract bv 
General Electric for the Avionics Lab, APWAL/AA Eee) PAGER SO Read tie 
Software Life Cycle Support Environment (SL@SE) being developed by sGenees 
Research Corporation under sponsorsnip of the U.S. Air Force Rome <aAir 
Develooment Geman GA a a? 


Ill. CASE DEVELOPMENT ISSUES FOR MISSILE SOFTWARE 
BRANCH (MSB), CHINA LAKE 


A. MSB BACKGROUND 
\{SB is a small software research and development group. They are a branch of 
the Weapons Development Division, Micheison Laboratory, Naval Weapons Center. 
eed cml AOmid- oO inc mememecrs I) tae 2rqup are domain specialists in 
Cligoera, ciacedded missile soltuarc. Prior tO Current efforts to use Ada, virtually all 
of their work involved assembly language programs for unique processors with 
extremely limited resources (e.g., speed, memorv) in onboard, mission critical, reai-time, 
embedded missile svstems. Working around constraints like limited memory often 
requires methods (e.g., unstructured design) which subsequently make the software 
extremely difficuit to understand and maintain. Reuse of such hardware specific and 
unstructured software 1s virtually impossible. Knowledge of the weapon domain (a 
major factor itself} is often the only reusable resource in this software engineering 
process. Hardware advances with the potential to improve the resource (speed, 
memery, etc.) availability of potential target processors, and the increasing availability 
of Ada compilers fer target processors. have opened the door for MSB to exploit Ada’s 
inherent support for structured methods, obiect oriented software engineering and code 
POMa cite > 
i. Mission 
Tae basic mission of MSB is to establish and maintain a Navy in-house 
capaoility for developing state cf the art mussile software. As with anv research 
Criented organization, they are considered a resource for exploring new technoiogies 
Which ‘vould likely remain unexplored in the profit oriented private sector. As a 
fo Open resource ttev May De tasked to perform someor all of the development of 


FOlmuarTe (Or specilic mussile projects, 


“Onboard embedded software operates in a unique environment. Size, weight, 
power, and heat dissipation continue to be a major concern, and even today the 
mermory-is-cheap scenario may not apply. Efficiency of object code generated bv target 
machine Ada compilers is also of major concern. (Mvers, 1987, pp. 71-72) 
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-. Problem 

Hardware advances (é.g.. VLSI!) have proliferated embedded processonsmimre 
Weapons svstems projects at an ever increasing rate. The impact of new technologies 
on the operational environment of the weapons (e.g., operational deception, electronic 
warfare. etc.) demands increasing capabilities for mission fulfillment. New technologies 
make new mussion capabilities possible and. or essential. As a result, mission critical. 
embedded system software demand (both upgrade of existing systems and new svstems 
development) is increasing rapidly. 

Current federal policy on personnel funding effectively limits any increase in 
\M{SB personnel resources in the foreseeable Tutune,s Projects stejected duicumma 
insutficient capacity) by MSB must either be done somewhere else (generally private 
sector ccntracts) or be abandoned or postponed. For manv projects, especially 
research, the mussile software domain expertise of MSB makes them the best equipped 
for the job. Otner considerations, such as secunty of operational environment 
intelligence and hardware advances, can make in-house research and development 
easier, more desirable and less expensive. Our purpose here is not to attenipt to 
quanulv capacity shortfall at \{SB, or its cost im terms Of private sector Cantraciomen 
unexplored avenues of research. But, to report ViSB Ss own dssessment that ticuse. 
unable to keep pace with demands for their services. 

3. Organization 

The largest organizational subgroup within MSB is known as the Software 
Technoiogy (ST) group. This group, currently seven software engineers, is engaged in 
Various projects often involving only one or two people per project. These projects are 
primarily researcn oriented (e.g.. rapid prototvping for feasibility demonstration). The 
customer sponsoring such projects is generally the project manager (not part of MSB) 
for the particular weapon system involved. Also. independent research of a less svsrer7 
specific nature (e.g., developing and benchmarking Ada library packages) may be 
sponsored by the branch. department or Some Other denwmty. Besides the 3 | erouems 
team of three software engineers and a program librarian are currently engaged in a 
Jevelopment project for the Sidewinder missile. There are three software engineers im 
the Soarrow missile development group. There is a Software Acquisition Contracting 
Manager group, of two, who are dedicated to configuration and documentation 
management for the branch. Finally, there are a Branch Head and a secretarv bringing 


the total to 18 personnel. Development teams are formed irom > le2roup per-ome! 


aecctomanamretinmetomthe S| group swwhen development projects end. This is a general 
descripucn of the MSB organization and the degree of flexibility in their software 
engineering process required to meet their committments. 

-. Current Environment 

MISB has been actively improving the environment within which they work. 
Management tailors the soitware engineering process to the task at hand. Research 
projects may proceed emploving structured methods and top down design for rapid 
prototyping without pushing the entire bow wave of static sequential life cvcle 
constraints required (e.g., bv DoD Standard 2167) when a project enters development. 
Umma w es hUctined Metiedelaries espouscd by Yourdon and others. ISB is 
actively engaged in research to demonstrate Ada feasibility for missile software. This 
work includes performance analvsis of object code generated for potential “off the 
sneif” target processors. They are developing expertise in object oriented design with 
Ada. Thev are actively researching nussile software domain Ada library packages and 
working towards reuse of design and code. Thev have sponsored development of an 
Ada code analvsis metric (Halstead metric) tool, AdaA\leasure, (Fairbanks, 1987) at the 
Naeeerosteraduare school) {N\PS)) Whew have encouraged other NPS efforts ‘ 
including this one, which focus on aspects of CASE resources and development. 

To the extent possible with available funding, MSB has upgraded the 
hardware and software of their host development svstem. The result to date is a 
disjoint environmient of personal nucrocomputer workstations with local area network 
Sonia eaceessuegutecit OWN SUPCr-mucrocomputer amd thecentral site processors. The 
Dish acco wstuns the (xix operating svstemiand hosts various Ada compilers 
meen Cacmn OOO moelsa cc. Gdeeterers}= simular resources are available on 
“ewecentralssittems vy... “SMHEMMDETSOnal cOnipuler Workstations generally have 


individualized coilections of disjoint tools for word processing, text editing, scheduling, 


"Under development concurrently with this work. these efforts will also result in 
June i987 theses. While titles are not yet firm, the works are identified bv subject and 
author: 


e An Ada Ternunal Interface Package. bv Anthony Keough: 
e Improved AdaMeasure (Henrv Kicur metric), oy Paul Herzig; 


® Interactive Graphics in a CASE Environment User Interface, bv Gregg Singer. 
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Recognizing not only a need, but an obligation, to remain a viable research 
and development resource, by remaining competitive in terms of development Cost, 
sroductivity, and availabilitv, MISB 1s actively investigating CASE environments. 

5. CASE a Desired Solution 

In the Fall of 1986, MSB began to actively explore CASE solutions to 
improve productivity, reduce development costs and improve product quality. Their 
high level requirements included automated resources supporting the following: 


e CASE environment database containing code, documentation, specifications, 
requirements, transformations, design histories, project summaries and cost 
projections integrated with graphic design tools; 


e library, supporting reusabilitv of source code, documentation, tests and test 
diiasancdegoleer code: 


e documentation generation, supporting their research, prototype process and the 
development process (DoD Standard 2167 and other requirements): 


® graphical analysis and design. supporting Yourdon — structured 
analysis structured design methodologies and Ada object oriented design: 


* programming support including stvle guidelines, static and dynamic analvsis and 
SOurce aiimeonjec: code gencraucn: 


e office automation, supporting project management. 


In addition, they identified hardware resource constraints including support for: 
¢ networked software library (database): 
e modern graphics oriented methodologies and tools; 


¢ team approach to software development. 


Thev reiined these hardware constraints further to: 


e multutasking, supporting parallel simultaneous interaction with environment 
resources; 


® mega-pixel graphics resolution, supporting multiple virtual terminals for parailel 
simultaneous interaction with concurrent tasks; 

* mega-instructions per second, supporting resource-intensive features of the 
system; 

° ega-bvtes of main memory, supporting resource-intensive features of the 
system. 


(Missile Software Branch, 1986, np. 6-8) 
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B. CASE ENVIRONMENT PROCUREMENT ISSUES 
Within DoD, procurement of any large, expensive. complex svstem cf hardware 


nd software (like a CASE environment) is governed by policies and standards which 


pee) 


require such things as demonstration of economic feasibility and documentation of the 
ceveiopment life cycle in a systematic way for management as the procurement 
pie oye Ol) Siondard 2167 Tealmmesients)= llr purpose here 1s not to study 
Se prOcessemOUtl 10 sdiSCUSS sOine Cemencieassucsmavhich would arise during such a 
procurement. A fundamiental issue is a consideration of make versus buv. By make we 
mean co make or nave mace (e.g., under contract) a system which ts designed topdown 
(ec tesUmidiceGhcanizatian and SOlmuare Engineering processes of VISB. By buy we 
mean a svtem comiposed of existing (off-the-shelf) products which are purchased to 
assemble a CASE environment. We will discuss brieflv two fundamental aspects of the 
buy Option. [nm the first case one biixs a collection of tools or toolsets from a variety of 
sources, choosing each for the particular functional resource it provides. Because of 
the general current state of the marketplace in tools (1e: lack of consistent user 
Weems eck GO) Imicropelaoility, etc.) tes best result of this approach 1s a disjoint 
environment assembled in a bottom up fashion. We call this a short term appoach. In 
the other case, one buys a complete environment (in todays marketplace there are few 
choices) which has been designec top down as an integrated environment. We cali this 
a long term approach. 
1. Short Term Off-the-shelf Buy Approach 

a. Advantages 

(1) Inunediate Results. Compared to an environment as a whole. a tool 
with limited functions is relatively inexpensive. Thrs will often allow funding from 
lower levels within a bureaucracy with less justification and shorter procurement 
deiays. The tool can be in the working environment much sooner. 

(2, Ease of Extensioility as User Experience and Technology Evolve 
Requirements. Tne relatively small investment in any partcular tool in the 
ivironment, allows easier justification and funding to enhance the environment by 
adding a tool which fulfills new requirements better than existing tools, or adds totally 
ere ine ans. 

(2) Pick Best of Available Tools. As discussed previously with regard to 
the dilemmia of integration versus a variety of sources, this approach encourages access 


to the best technolegy available now or in the future. 
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b. Disadvantages 

The advantages listed above lead directly to some major disadvantages. 

(1) Short Term Solutions Create Long Term Problems (e.g., Creeping 
Evolution of the Environment). Within a software engineering environment. the issue at 
hand is production of a software product. The product is more than just the object 
code. Change (maintenance in the traditional view, or evolution in the 
ransformational prototype development view) of software is generally accepted as 
inevitable. To be able to change object code in an efficient and responsive manner 
(without starting over from scratch). 1s a major (if not the major) purpose for the 
development environment. At a minimum, the environment should facilitate the 
archival of the product in some durable storage media from which the development 
process can be recreated exactly and then evolved. Since the product ts a direct result 
of the specific tools used to create it (and the tools themselves are programs which are 
not provably correct or identical), the only guaranty that a recreation from the archives 
is precisely the same product iS if precisely the environment sused ingtie solmu mn 
engineering process is also recorded in the archival process. If the environment 1s 
subject to creeping evelution the task of archiving becomes very complex as multiple 
versions Of a tool. or even totally different tools; may have been used in developingata. 
same or different parts of the product at the same or different times. 

(2) Disjoint Environment. While each tool may add to overall productivity 
ll) a specific Way, the additional overhead involved in using a disjoint environment will 
resuit in the overall productivity gain being less than the sum of its parts. In contrast, 
synergistic gains in productivity and quality should be expected from integrated tools 
(e.g., a debugger which works with an object created by an editor, as source code, and 
1s capable of changing the object without forcing the user to shift modes (leave the 
debugger and re-enter the editor to make the change)). 

(3) Inconsistant User interface. With rare exceptions, the user interfaces 
from one vendor of software to the next vary consideracins WV hile manasa ties saan 
shis is only of concern with novice Users who must learn larse number of interiagesean 
the same time, we feel it 1s a majoriconsidefation fom expert users as well. The exweu 
user may make fewer mistakes than the novice because he knows which Anobs operate 
the svstem in each of the modes of operation imposed by the various disjoint tools. 
But, there is a cognitive investment. in navigating this modal hierarchy, which must 


detract from the creative work (he UWSser Is tring Comaecomimlicn In ties process) war 


the training overhead required to create expert users (including acceptance of the new 
environment -OV eXisting users in the first place) will be much higher than with a 
consistant user interface. 
2. Long Term Off-the-shelf Buy Approach 
a. Advantages 

(1) Long Term. Since this approach invoives a complete environment. we 
are talking about a major investment in both hardware and software. Once such a 
system has been procured 11 ts likely to remain quite stable for relatively long periods of 
time. Because of its large mass as an investment it will tend to have a great deal of 
resting inertia. The developers’ changes will be consistant with the overall design to 
protect the Users investment. Creeping evolution is unlikely. and any evolution is more 
easilv traceable due to reduced complexity in the number of vendors involved. 

(2) lategrated Resources (within this CASE environment). One should 
expect sVnergistic gains in productivity and product quality. 

(3) Consistent User Interface. A consistent user interface is not 
guaranteed just because the environment is the product of a single developer. Neither 
(eine Cove) iere (iam one developer is involved. Since there are a variety of 
possibilities. and no one well accepted standard, it takes a committment, bv the lead 
cevelo@er, © 42 Consistent interface philosophy. One relatively successful approach to 
this is the Apple Maciniosn interface. While vipple themselves followed a consistent 
Dien tceme tie  saisouinvested in the futuge bv prowidine the soclbox of resources, in 
system firmware, which make it easier for application developers to simply conform 
Witn the J/acinfosh interface than to invent something new and different. 

b. Disadvantages 

(1) High Cost. This approach requires an up-front committment to a 
major hardware software svstem representing a major investment of funds relative to 
that involved for individual tools. Local approval and funding are less likely. 
Justification of the system to a higher level of a bureaucracy is generally more formal 
and takes longer. 

(2) Sole Source. Unless his product has a well established market share 
and the vendor is clearly a healthy business concern, there is a great risk in a major 
iMvectmecmuIneaisesrouuct, (\O One wants to be the first, and possibly only, customer.) 
This risk is even greater if the product involves a unique hardware architecture required 


to host the environment. The user may be effectively limited to tne vendor's 
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technological and proprietary vision both for what is included in the environment 
todav and how it will evolve in the future. The resting inertia which makes this a 
stable long term asset may inhibit extensibility in stride with the advancing state of the 
art. Also, an off-the-shelf complete environment may include resources which are not 
applicable or useful for the MSB software engineering process. The customer naturally 
resists paving for something he will not use. 
(3) Incompatible Data Formats (with other development environments). It 1s 
a natural extension of the idea of interoperability within an environment, to also 
consider interoperabilitv between different environments. If for example MSB is tasked 
tO prototype a proposed change to an emibedded software product developed for a 
project bv some contractor, the process would be significantly enhanced if the MSB 
CASE environment could accept and operate on the model of the svstem and all of the 
objects developed in the contractors original software erigineering process and 
environment. 
3. Make Approach 
The make approach shares many of the disadvantages of the long term buy 
approach. In general terms it appears to far exceed existing MSE resources. In 
Chapter IV, we will discuss some of the inherent risk for anv sole development of a 


CASE environment. 


C. WHICH WAY FROM HERE 

In order to effectively make décisions which commit scarce resoutrcesmane 
developing a CASE environment for MSB. managers in the MSB chain of command 
must understand. the software engineering problem and how it relates to the 
productivity of MSB, as well as what a CASE environment is intended to be, and do, 
to improve productivity. An understanding of general CASE environment development 


issues, and principles for a good CASE environment will also help. 
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LV. CASE ENVIR@GNDENT DEVELOPMENT ISSUES 


A. SCOPE OF CASE PROBLEMS 
‘As previously mentioned there are a number of products on the market which 
use the term CASE in their descriptions but only amount to tools, or toolsets, limized 
tO a portion of a full life cvcle software engineering environment. A life cycle view of 
CASE entails some major development problems which are reflected in the general 
state of this technology today. 
1. Evolutionary Development Politically Necessary 
High risk is the driving force behind evolutionary development of CASE 
environments. Because of the size and complexity of a CASE environment, and the 
Immaturity, instabilitv or rapid evolution of the fundamental components involved (e.. 
languages, database technology. management techniques, software engineering 
methods, economic models. hardware engineering, graphics. networking. ergononiics. 
artificial intelligence. etc.), the classic problems of software engineering applv to CASE 
environment development. Delinition of the problem (the software engineering 
process) 1s generally incomplete. or inconsistent. and likely to remain so for sometune 
[on Poems Oll vale Industiueas, 2 siOlewsAcearesult, no clear industry wide set of 
hoot ine emis ommcesaliSiicg Oy the enviroOmment has emerged. Likewise, no clear 
agreement on fundamental issues regarding data models and component interfaces 
within environments cr among environments have emerged. Most of domestic industrv 
ee om Gk tecmresolicces and Motivation tomundertake a full life cvcle CASE 
environment development project under such high risk conditions (uncertain of the 


direction each of these technologies will take). Asa result, most efforts nave continued 


not likely to suddenly go away. The software engineering process may be well detined 
for 2 particular organization in which the majority of projects follow simular life cvcles. 
oe G creeiic likels (Nat Several distinct environment markets exist. and committment 


to a single life cycle model would constitute a committment to a single vertical market. 


European developers seem to be way ahead in top down development of 
tee eerse. [ull We evcle CASE environments. 
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2, Requirement Tradeoffs Contributing to Risk 
Among the manv traceoffs involved in CASE requirements analysis are: 


e low(e gc UNI ie eeichintecramon 
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0 closed vs. open environment (extensibulty): 

e language dependence vs. independence; 

@ menolingual vs. multuingual; 

® partial vs. full life cycle support: 

* single vs. multiple methodology: 

e single user vs. multiple user; 

* hardware dependant vs. independent; 

* [eX VG crae es 

e system configurable vs. user configurable: 

a TOnesecliie vs. secure: 

e cost effective vs. cost exorbitant 
(Henderson, 1987. p. 48). What is needed is a committment to a CASE environment 
development philosophy which will allow evolutionary development of good 
environments, Wile muinimuzing risks from changing software engineering process 
requirements and continued technological advancess™ First, lets comsider wie 


constitutes a good automated environment for software engineering. 


B. FUNDAMENTAL PRINCIPLES FOR CASE ENVIRONMENTS 

The background discussion of the preceding chapters included several issues 
which have influenced the evolution of CASE environment eifortss9. ye Cider 
discover any clear cut study or statistics proving one side of certain issues to be 
superior to the other. One can get a feel for thestrend of developments mean 
acceptance and the direction of ongoing research, bv examining past and continuing 
work with environments. A strong dose of common sense can then be applied to the 
issues, and choices can be made which appear to be fundamentally better than the 
aiternatives. An objective study to demonstrate that these choices are superior to their 
alternacives 1 certainiy a direction for flrther research, Dut tar exceeds the scopesonm 


this work. ° 


‘It seems that few such studies are ever conducted. Such a study must of 
necessity foliow implementation of the principles involved. Then each of the 
alternatives need to be applied im paralic] to the same problem in an Gnvinonined: 


where other variables (software, hardware, people, cic mare secomroled (nor dome 
difficult and expensive). As has often been the case with past developmients, if a iactor 


Leon Osterweil (1981, pp. 36-37) wrote that, 


The essence of a software environment is the synergistic integration of tools in 
order to provide strong. close support for a software job. This environment must 
have at ieast these five characteristics: breadth of scope and applicability, user 
triendliness, reusability of internal components, tight integration of capabilities, 
and use of a central information repositorv. A support system must pecssess 
chese Ciiaracteriscics if 1t 18 tO merit the name environment. 


This six vear old view of what should characterize an environment has not generally 
been attacked or disproved. seems to represent the consensus of todavs stated goals for 
Cn ile (met (sem, 1S aime essence Olainat weucall findamental principles for CASE 
EUMinen ens: 
1. Portable/Reusable CASE Resources 
We view environments as a collection of resources. The collection includes: 
® physical resources, consisting of computer hardware and svstem software and 
iirmware: 
1G = fesources, “Consisting Of soliiware tools implemented on the phvsical 
resources: 


* manual resources, consisting of the methods and procedures necessary to the 
P@llpt are ENGincering process but mot implemented as CASE 
resources; 


¢ human resources. consisting of the people who use and facilitate utilization (in 
the case of manual resources) of the environmient. 


Open roc. Sone CAGE tTesources. Natural, the CASE resources implv the 
minimum xhvsical resources required for their execution. Thev also define the 
automation boundaries for a software engineering process in a given environment 
thereby determining the nature of manual and human resources. 

CASE resources should provide the software engineering team (human 
hese cov Wied Dp Oblemi solve Interiace between the real world problem (for which 
Pier euistede,c ODMdsOll vane SOlMiemieanG tne Manual and physical resources. A 


broad, shallow, functional hierarchy of resources, is required to support user frienaly 


like procuctivity (which is inherently difficult to quanufy with precision) 1s noticeably 
improved bv the change, the industry tendency seems to be to accept and exploit the 
change. If the advantage of the change is not clear, it is resisted and either limps along 
(eee eiminommurne, share Or dies ott bv natural selection. In either case there seem 
to have been few attempts to objectively quantify the relative advantage of the 
alternatives involved. At best. empirical order of magnitude comparisons of simular 
issdley are comducted. 
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goals (discussed later). By shallow, we mean a hierarchy with verv few lavers. This 
facilitates responsiveness by reducing the calling overhead required to descend through 
the hierarchy in order to use phvsical resources. Subordinate layers in such a shallow 
hierarchy will be broad in the sense that they will of necessitv contain manv resources 
(if modular design principles of coupling and cohesion are observed). In such an 
architecture, kernel utilitv resources (with unique, independent functionality) direcily 
access the hardware resources Or the environmient data medel (the Kew GAS cseume se 
on behalf of tool resources which provide CASE environment Services to) tlie susey 
interface. Such an architecture enhances portability and reusability of Software 
components and extensibility of software systems. 

The issues of portability and reusability of CASE resources and extensibility of 
CASE environments are fundamental to risk #$management. CASE 
environment, resource user risk will be reduced if their investment is secured well into 
the future (inspite of hardware, methodology, and other technological advances). 
CASE environment, resource developer risk 1s reduced if their products reach a broader 
market (various hardware and methodologies) with greater longevity. Unfortunately, 
the same competitive market dynamics which encourage technological innovation tend 
to discourage reusability and portability. Hardware and software developers who rely 
heavily on the direct linkage of their respective products, to control their Share Ole 
market, tend to resist (often in subtle ways) industry standardization efforts which 
might undermine their market leverage. 

2. Integrated CASE Resources 

All of the CASE resources in an environment should be integrated to facilitate 
coherence, control and sharing (see Chapter |!) in order to vield a ssnereistic cilee 
whereby the utility of the environment as a Whole is more than just the sum Of its 
parts. Recall that with respect to automated environment tools, in this instance CASE 
PESOULcese Ver celine immectabcanac: 

e all resources conform to a consistant user interface: 
@ all resources are as highly interoperable as possible; 


® objects and their interrelationships are in a persistent common data format: 
which is meaningful to all environment resources. 


The consistent user interface and interoperability allow for intuitive access to CASE 
resources relieving the user of much of the cognitive overhead of navigating among 


Various tools. with various operating controls. The user can devote more of his 
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attention to the software engineering task at hand. Interoperabilitv, based on 
manipulation of the common data model by all CASE resources, should allow the user 
to create Or change an object by manipulating anv of it’s displayed forms. 
(MacLennan, 1987, p. 1-3) 
3. Open Environment 
To enjoy the benefits of new technology and competitive endeavor, and 
encourage evolutionary development for multiple environment markets, environments 
snould be open to extensibilitv. To support reusability of resources, functionality of 
existing CASE resources should not be diminished by new resources. To reconcile 
extensioility with the seemingly conflicting principle of integration requires agreement 
on and standardization of: 
® data model used to represent objects and their interrelationships; 
2 interfaces of CASE resources with the data model: ” 
Stren decsg] ©ASE resources with physical resources: 
eer tidicess®, CASE resources Witheene User. 
4. User Friendly 
Pcepeene me ised much OvemMveneu lefimembut weve chosen to use it for 
consistency with Osterweil. Commitment to an integrated CASE environment 
composed of CASE resources as described above can facilitate an event-driven user 
interface phuosophy. Such a philosophy is characterized bv: 


® responsiveness, users actions have direct results, are intuitive and spontaneous 
(Hes mesos): 


® permissiveness, the user can do anvtning reasonable at anv time. the user decides 
iat miOma GO Nextesm@l tie Indiviaual CASE resource (1.e., no 
modes); 


®* consistency, regardless of what CASE resource is in execution, the user's 
control options and the apparent response to them are consistent 
with the tvpe of function being performed (e.g., anvthing that 
seems like text editing should use identical controls regardless of 
whether it involves labeling a graphical diagram or generating a 
fextual Gocunicaia 


"“The database provides an integrating and unifying medium for interfacing tools 
without forcing them into a complex structure of interrelationships. Tools obtain their 
information from the database and return their results to it without having to interface 
directly with other tools... . In order to maintain flexibility it is important to avoid 
building bridges between pairs of tools rather than bridges into the database.” 


a 
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The feel of such an interface should be that the environment is waiting to serve the 
user as opposed to the other way around. This is done by emploving an event-driven 
control structure where user actions are events and the svstem is always ready to 
handie them (e.g., as priority interrupts, or by polling for them). The broad shallow 
architecture. of the CASE resources in the enviroment ?qemmavesmev cite mlm 


without modality. 


C. FUNCTIONAL ABSTRACTION AN APPROACH TO SOLVING 
PROBLEMS 


The principles may not have changed significantly in six years. but CASE 
environments embodying these principles are not generally available. Without 
belaboring the point, we attribute this to the high risk of building on questionable 
standards in rapidlv changing and relatively immature technologies. We propose a 
strategy, to avert some of said risk, allowing progress towards these principles. 

1. Definition of Abstraction 

An abstraction is a description of some object which separates the defining 
properties of the object from the unnecessary details about it. A software engineer is 
concerned with solving some problem. The tools (CASE resources) in his software 
engineering environment form a problem solving abstraction. The hardware (and some 
of the software). on which the problem solving abstraction (the CASE resources) are 
implemented. form a physical resource abstraction (Yurchak, 1984, p. 3). 

2. Formal Specification 

It is generally recognized that the operating svstem is an abstraction of the 
hardware svstem of primarv and secondary meinorv resources, processor resources, and 
Input output resources. Additional abstractions (¢.g., video display resources) have 
also become commonplace. Such abstractions generally exhibit lack of formalism or 
consistencY, a semantic gap, similar to the problems faced by linguists trving to specify 
the semantics of language constructs. “The vital property of a specification which 
guarantees that a correct program corresponding to it may be constructed, is... . its 
consistency.” (Lehman. 1984, p. 39) The practical problem to be solved invoives the 
portability of software. One must be able 10 specify resources, in an iniplementidem 
independent manner, in terms of abstract functional properties they provide. Davis 
(1984). using concepts developed to specify the semantics of high level language 
constructs (particularly abstract data types), developed a method for algebraic 


specification to solve soine of these problems. Using such a formal specification as an 
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external framie of reference, correctness of a program developed from the specification 
can be viewed as a calculable, instead of empirical, notion (Lehman, 1984. p.39). The 
imehecation is that a correct implementation of a problem solving resource, layered on 
tcp of correct implementation of physical resources, will alwavs behave functionally the 
same regardless of the implementation or hardware details. The way is then clear for 
eevelooment of portable, reusable, funciona! resources. 

5. Abstraction of Physical Resources 

Yurchak (1984) used Davis's algebraic formalism to specify AM, an abstract 
machine (physical resource) from functional requirements. Multiple instances of AM 
have been successfully implemented, from Yurchak’s specification, on different physical 
hardware at Naval Postgraduate School. Implementation efforts proceed quickly and 
mechanically without the semantic ambiguitv of less formal specifications. Work 1s 
continuing testing portability of applications running on AM when hosted by different 
ehvsical hardware. 

Grant (1986) functionally abstracted resources to support graphic user 
interfaces. He hosted his abstract resources on the Apple Macintosh and Digital 
Rescorvcn s Glewwion the IB Vi P@)) Applications. using onlv his abstract resources, 
are portaole between the two host implementations inspite of significantly Uifferent 
Pere arewanaesvsteni soliware (9m difterences between color and monochrome are 
handled bv the abstraction by placing colors within a gray scale, from light to dark. 
causing themi to be Cisplaved in logical shades of gray when hosted on monochrome 
harcware.). There is no noticeable (from a Auman interaction perspective) degradation 
in the response time of applications using Grant's abstract resources vs. sinular native 
Ste me esenlrces (oop mrOUse trackin®) On either host. This is attributed to Grant's 
adnerence to the broad shallow architecture principle for portable reusable resources 
sunporting user friendliness. At most two levels of calling overhead are added between 
an apolication resource call and the native svstem resources. 

4. Abstraction of Environment Resources 

By defining abstractly the basic functionality of CASE resources based on a 
useful standard data model, and impiemiented on abstract hardware resources, software 
developers may be able to drive CASE development with nunimal risk from the 
uncertainties of hardware evolution. language evolution, and even evolution of the 
sottware engineering process. One key is agreement on a standard data mocel capable 


of representing all of the objects (1.e., real like people, programs and documents, or 
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imaginary like yet undeveloped programs or unhired people) and their inter- 
relationships Which compose the software engineering environment. CASE resources 
must assume basic hardware and svstem capabilitv as specified for the abstract 
hardware resources. Once a CASE resource 1s operational on the abstract hardware, it 
would be portable to any physical hardware capable of hosting the abstract hardware. 
Given an abstract hardware host, fully integrated environments could be assembled 
from abstract CASE resources. An environment duilder could design and implement 
his own preferred consistent user interface which interacts with the abstract CASE and 
physical resources. But, ideaily he would find it easier to adhere to user interface 
guidelines making use of CASE resource utilities which directly and efficiently use the 
abstract physical resources to provide a responsive, permissive, consistent, human 
engineered user interface. New resources could be abstracted, as technology advances, 
by adhering to the specified data node! and imnitenimecs: 

Such an aproach is directly pointed to by efforts suchas CATS and PG@ite 
We beiieve efforts in this direction hold some promise for bringing order to the current 
environment chaos. 

5. Lavers 

The question of efficiency often comes up in connection with our advocacv of 
lavering abstract problem solving resources on top of abstract phvsical resources on 
top of actual physical resources. This is certainly an area of concern since 
responsiveness is One of Our user friendly requisites; and many CASE resources miaw ae 
physical resource intensive (e.g., manipulation of many interrelated objects in a large 
project database). A key to this issue 1s our advocacy of a broad shallow Iherarchy of 
CASE resources facilitating responsiveness of event driven user interfaces and resource 
intensive toois, and providing rapid access to physical resources by avoiding a deep 
modal hierarcnv. Grant's experience indicates that this can be a viable approach for 
supporting user friendliness in an interactive graphic user interface. The speed of 
physical resources has been continuously increased by hardware advances, and more 
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recently through multi-processor architectures. *~ so it seems reasonabie to argue that 


PUN aia example, the Multi Backend Database Svstem (MBDS) at the Naval 
Postgraduate School provides for distributing a database evenly among multiple off- 
the-shelf backend microcomputers. Database size can be doubled, with no impact on 
transaction time, if the number of backends is doubled. Or, the response time can be 
halved by doubling the numoer of backends while maintaining database size. The 
nu:nber of backends is transparent to the users who deal with MBDS as an abstract 
dataoase resource which supports multipie data models and multiple query languages. 
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small efficiency gains in CASE resource implementation, at the cost of portability and 
reusability. are likely to be wasted in the long run (i.e., if vou must scrap non-portable 
resources in Order to take advantage of more significant performance gains offered bv 
technological! advances). 

In addition to efficiency considerations, a major consideration, in constructing 
@esemict resources 15 identifvine the indmadual functions to: be provided. As Ostervell 
(1931, p. 3") ovserved. different application areas will inevitably lead to differences in 
environments to support them. The bottom laver of problem solving resources should 
De atomic functions which directly support multiple top layer resources. As an 
examiple, an atomic resource mught be a parser which 1s called by pretty printers, error 
Checkers, static analyzers and compilers. etc.. The philosophy for developing 
envircnments should use information hiding to protect the integrity of these basic 
layers. In other words. the users of top level resources only interact with those 
PeSOUTCeS amon instance, the comipiler user sivewldeonlvanse the comipiler. The fact that 
Cie wm@iatee, even enise should be hidden ivome him, Those abstracting too level 
Rese (pero \)O%, (he Paksch exiSts. DUL Gmly access the parser in terms of its abstract 
functional interface. If the need arises to jump around a layer of abstract resources to 
get at some lower function, then a function which should have been abstracted has 
oeen nussed. This is one reason why high order languages like Ada or Pascal dont 
produce portable applications. Abstraction in these languages is at an extremelv high 
ievel (the pregramiming logic level), and hardware or operating svstem calls are often 
required to handle external interfaces (e.g., input'output devices). In the case of good 
Proc diemucsicimmliese stay be collected Minte. abstract interface packages and 
documented as requiring change before porting. By abstracting at a lower level, and 
being commutted to a philosophy preserving the integrity of lavers of resource 
abstractions, portability and reusability of environment resources may be achieved. 

6. Standards Enforcement vs. Encouragement 

One thing the software industry has is plenty of standards. As part of the 
original STARS-SEE effort, Institute for Defense Analyses conducted a study of 
information interface related standards. They identified 772 existing standards and 422 


tl 


emerging standards Onn iMicananondigue onmeOvelliment, or industrial, 


organizations. The study focused on standards, in 25 categories (e.g., data interchange. 


Ware category of emerging standards included both standards oriented 
development projects and commercial ventures becoming defacto standards by virtue of 
Miamie: Share: 
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project management, graphics, programming languages, etc.), considered of possible 


relevance in defining integration requirements for the STARS-SEE (Nash. 1985, p. 


The fact that so many standards exist, and so manv more are developing 
suggests that standards are anything bur standard. Many standards are the result of 
noble effort bv standards organizations. But, adherence to such standards. bv 
developers, can be a high risk proposition. If the standard is something new and 
different. there is no easily predictable market for a product conforming with it. 
Success of such a product (its market capture) is deternuned by a multitude of factors. 
[f the product is measurably or noticably superior to some existing successful product, 
or provides some entirely new and highly demanded function, and is targeted for 
physical resources commanding a significant portion of the likely user group, it will 
probably be successful. This is risky business, and many standards on paper never 
become standards in fact. Some standards of necessity (e.g., hardware interconnection, 
external conimunication protocols, etc.), many of which began as defacto standards. 
are broadly accepted as mutually beneficial to industry as a whole. Other standards, 
such as those promoting software portability (im this case CASE resources), manmae 
viewed favorably by users. and developers without a vested interest in particular real 
physical resources. However, much market selection of hardware currently involves 
issues concerning the breadth and depth of software applications available for that 
hardware. If software were more readily portable and reusable a major hardware 
marketing lever would be altered sicniiicancne 

As stated earlier, hardware and software developers. who rely heavily on the 
direct linkage of their respective products to comtrol theim Share of the nidtkelsicmaere 
resist (often in subtle ways) industry standardization efforts. If their market share is 
large enough. they collect strap hangers seeking some of tnat market. It 1s in this way 
that defacto standards arise. Of course. at this point the authors of the defacto 
standard, wno have already profitted. mav change directions radically in a bid to shake 
off strap hangers who have not vet recouped their investment. And so, often with 
diferent lesser plavers, the cele becca ame 

In a few cases. such as the DoD Ada initiatives, a particular standard. or set 
of standards, nave been implemented and enforced by management dictate. [2 Ta the 


case of Ada, competition for DoD dollars has been the primary industry incentive to 


4 cC c : 
!2One may argue that Ada is far from being fully implemented. and that 
NANALeMeNLt Tresowwe IS NOl Percca clean 
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actually develop the resources required to support the dictated standard. One obvious 
drawback to this sort of approach to standardization is the fact that few interest 
groups have the financial clous required to pull something like this off. A more subtle, 
and im tne long run possibly detrimental, drawback (to standards by edict) is the 
possibility that the standard may not be a very good one, but gains momentum bv 
directive. and consumes resources which might otherwise contribute to evolution. 
through natura! selection. of something better. And, once in place, inertia will tend to 
Keep it there. Of course, if the standard is good, or at least acceptable, the advantages 
cf focusing resources and effort should be significant. 

The dilema of standards enforcement vs. encouragement is not likelv to be 
resoived. We favor standards encouragement for CASE resource functional 
aostracticn, interfaces, and data models. Kevs to standards encouragement are: 

e20e0 Re in. sO tere is litle imcentive to repeat the effort: 


e availability, if possible make all forseeable low level resources sufficientiv 
efficient and readily available so there is little incentive to violate 
laver integrity (bv jumping around it), and little incentive to 
reinvent tne wheel 


¢ cuidelines, well publicised and justified philosophy of why it is the wav it ts 
ane OW torneep it that wav. 


° social change, growing recognition that standards promoting plug compaubility of 
CASE resources with eachother, users. and physical resources. are 
also standards of necessity. 


~. Fop Down or Bottom Up 

One of our major criticisms of the current state of most CASE environment 
development has been the bottom up path being followed. We've recognized some of 
the motivation for this. Commercial CASE developers are avoiding risk and plaving to 
the disjoint off-the-shelf tools market. In order to survive, software developers (CASE 
resource users customers) in the competitive crenches often require immediate support 
(some of which is available in disjoint off-the-shelf tools). One significant by-product 
(from the long term view) of this activitv has been the generation of experience. with a 
variety of capabilities, as a base for identi%ving problem solving resource functions for 
aostraction. 

The top down activity in our CASE environment development strategy begins 
with the analvsis of a basic software engineering process to abstractly specify the data 
model and interface requirements (which are the infrastructure of the environment), 


and the functions (at lower lavers) and their aggregate (at successive higher lavers). 
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which together with the type of data they manipulate. define the resources of the 
environment. Design then proceeds hierarchically with more complex resources 
specified in terms of more primitive resources in the adjacent lower layer. Algebraic 
formalism associates meaning to the specification of each resource, with a rigor which 
can be used to calculably verify implementations of the resources defined in the 
specifications (Davis, 19387) por 30-2e=aee7 
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V. FUNCTIONAL REQUIREMENTS ANALYSIS ISSUES 


ao oC ORE OF PIS ERFORT 

PyeCligoter wee Veeeiseussed CASE environment development tssues and their 
contribution to the existing chaos of disjoint tools, toolsets. and environments. We 
discussed general principles for good environments and how abstraction of resources 
anc a formal method of algebraic specification may help to achieve those principles 
and alleviate continuing chaos. We believe that this approach should be developed 
further to make good CASE environment resources which become the foundation 
building blocks of portable. reusable, interoperable CASE environments. 

In virtually all conceivable software engineering processes, starting from the top 
means analysis of the real world problem to be solved. It is clearly bevond the scope 
of this work to conduct an in depth anaivsis of the process required bv MSB. and the 
iiinewioma merrcny Of CASE enviromment resources required to support the process. 
Pe ee econ sO fin, fais more i the caccgory of general familiarization. [t is 
potentially useful as a starting point for more directed efforts. 

lreGtapier (ie ye Outlined three basic alternatives for MSB CASE environment 
procurement: 

* make: 

e short term oif-the-shelf buy: 

e long term off-tne-shelf ouv. 
Wie also indicated that the snake alternative very likelv exceeds MISB resources and is 
therefore infeasible. However, we would like to carry the make ideas, discussed in 
Chapter IV. a little further to illustrate some of the top level considerations involved. 
We are going to skirt the really difficult issues of a standard data model (based on the 
sofware engineering process whose definition we've also bypassed) and a data 
exchange interface (at a higher level than sequential character based text files). We will 
look at some functional design issues for a relatively well understood subset of CASE 


environment resources supporting individal programmer productivity (IPP). Y 


l2This is not intended to appear like the type of bottom up effort we have 
criticised. We proceed in this fashion because of time constraints, the exploratory 
scope of this effort. and the extremely broad scope, complexity, and uncertainty of the 
environment engineering task (which has contributed to the current chaouc state of 
environment automation in general). Our intended purpose is to advance uncerstanding 
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It is noteworthy that. with the layered approach we've advocated, most of the 
low level resources, required to support a subset like IPP, are also required support for 
other high ievel tools. As an exampie, all of the user interface resources, below the 
CASE tools resource layer, must be in place (as do the user interface guidelines), TPP 
tool resources will use the user interface physical. CASE, and manual (i.e.,the user 
interface guidelines) resources@just as all subsequent too] resources sifould Use tems 
the basis for the consistent, user friendly interface which is one fundamental attribute 
of an integrated environment. This sort of idea should help one to visualize the 
potential contribution of our approach towards open extensible environments without 


compromising integration. 


B. INDIVIDUAL PROGRAMMER PRODUCTIVITY (IPP) RESOURCES 

What roilows is a very broad brush treatment of a few of the concerns associated 
with functional abstraction of CASE resources for a small part of a CASE 
environment 

1. Physical Resources 

One might ask why (given the difficuty of bringing new standards into the 

marketplace) even attempt to abstractly specif physical resources. Por einstames 
absiracting operating system level resources is tantamount to defining a standard 
operating svstem (which has already been done on paper. but hasgmot succeedeaaia 
displacing defacto standards such as UNIX). Why not just adopt an existing defacto 
standard and buiid on top of it? This is what is generally being done today to achieve 
some portabiiity and reusaonity. Problems include: 


e ack of formalism in specification of these defacto standards, resulting in tess 
than functionally equivalent instantiations and inherent portability problemis; 


e knowledge of the underlving operating svstem laver, encouraging, or at least 
enadling, undisciplined users to bai/-our to the operating system, violating the 
lavered functional information hiding structure to produce applications with 
Innerent portability and reuse problems: 


e dwar functionality (1.e., more than one wax to accomphsh the same cine 
especiailv if more than one existing standard (e.g., an operating svstem and a 
seperate graphics kernel) must be combined to get at the hardware, which can 


of the problem, and the potential of our problem solving approach. at several levels. 

ther, more specific, work to demonstrate technical feasibilitv of functional 
components of this problem solving approach (some specifically cited in this work and 
others just commencing or being encouraged) are in progress at Naval Postgraduate 
School. We hope that our work wall provide sUilicemu back croid toms iii 
continued efforts in an organized top down manner. 
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iead to implementations of higher resource layers which are affected in different 
wars, by changes in the components of the physical resource layer. depending 
o:: how that particular impiementation accomplished something (violation of 
our unique atomic function interface principle for lavers). 


® critica: functions required but not extendible to existing defacto standards (e.g.. 
If the environment must be a trusted secure system, the verv presence of an 
existing OF Sri SMste mis Tikelwate prevent realizine security which must be 

designed in trom the beginning). 


Physical resource functions to be abstracted should be familiar. They include the 
nardware typically managed by the operating system, graphics interface and database 
management svstem. 
a. Abstract Hardware Resource Layer 
mea ostiact Nardware tesource Jayver represents the hardware virtual 

hardware !* that will host other phvsical resources (operating svstem level resources). 
The challenge at this level is to aostract needed hardware functionality (which can be 
met with existing hardware technology) in a way that allows extension (e.g., 
paranieterizing tne es tomes Newalmioierievelin a way that should aliow access 
to future hardware. ‘~ ) without compromising the integrity of the laver. Included 
sow Cesc (aneiar tines like: 

®  processor(s): 

¢ primary and secondary memory stores: 

© archival storage device; 

e bit mapped display: 

PRP Drinker planter, 

* pcinting device; 

e gxevboard: 

@ network communications (not strictly required for IPP, but certainly a 

hinderance to extensibility if not available). 


‘*The formal algebraic specification of abstract hardware may be implemented as 
virtua hardware hosted on some existing hardware. (similar to P-coded 


imp ementations) or it may be implemented as new physical hardware. 


*>Some crystal ball gazing should be beneficial, but even if the result does not 
allow the most efficient use of all future hardware developments, rehosting virtual 
devices to new hardware should still capitalize on features such as added speed while 
effectively porting the entire environment built above it. We see this sort of thing (on 
a generally smaller scaie) in upwardly mobile nardware families where, through 


emulation. the instruction set of an older machine, runs on the newer macnine, 
allowing porting of object code for the old machine to the new machine. 
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The abstract hardware resource laver represents the interface between real host 
hardware and an open, extensible, portable and Geusable environment of GAS 
resources. Of course, this nucleus can be broadened bv addition of other devives which 
must then be reflected back up through the resource hierarchy to (and down through 
the hierarchy from) the teoll resources which cam ucearieim 

Tt is Gbvious that the physical resources constrain higher level resources, 
and that higher level resources drive the demand for lower level resources. One should 
not work independently with either set when defining the functional resource hierarchy. 
Instead one must begin in one place (either the top or the bottom) and model the 
desired functionalitv. Since high level resources generally require an aggregate of lower 
levei functions, one should analyze the situation in a combined top down and bottom 
up fashion working both ends (required nigh level problem solving resources vs. 
available phvsical resources) towards a meeting point in the middle. The goal is a 
broad shallow hierarchy with atomic functional resources at the base which are called 
through the interface to higher layers bv resources providing compound (or aggregate) 
functionality (the combination of atomic functions from below) to the interface with 
the laver of even more capable resources above them. Working in such a fashion one 
might continue populating a CASE environment IPP subset resource nierarchy ds 
tollows. 

b. Abstract Operating System Resource Layer 

the name of this laver is virtually self explanatory. However, the laveuae 
expanded, bevond more conventional operating system functions, to handle database 
management and graphics functions. The resource categories include: 


e x rocess management (including multitasking which we consider critical to 
productivity); 


¢ memory management: 
e tlie system management; 


¢ database svstem management (the database system is essential to the 
interoperabilitv aspect cf integration in environments): 


* input, output device management; 

* graphics kernel. 
As before, additional resources mav be added (driven by the balance of requirements 
from above azainst capabilities from below). As an example, a securitv Aerne/ night 
be added (with hooks to security resources added to the abstract hardware laver) and 
criven from a security manager (in the CASE environment services resource iayer) 


supporting security requirements of the CASE tool resource laver. 


or 2) 
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2. CASE Resources 
These are the problem solving resources. They are intended to interface 
directly, and only, with the abstract operating svstem resource laver below, and the 
user avove. There are only two hierarchical lavers envisioned (to remain broad and 
shallow), 
a. CASE Environment Services Resource Layer 

Resources at this level are the basis for integration standards within the 
CASE tool resources. These resources are the result of the philosophy governing such 
things as the user interface design. Data interface standards are also resolved at this 
level. and utility Service resources (which have broad applicability among tool resources 
and provice a cohesive functional aggregate of operating system level resources) would 
aiso be included. 

(1) User Interface Service Resources. These resources provide services 
which directly support the user interface guidelines. '© Their presence is intended to 
promote voluntary compliance with the user interface by doing much of the work in 
advance and giving it to tool resource developers. Included would be: 


2 «event manager, the neart of a responsive user friendly interface, reports events 
SO Olio de ice Wo. cmenms, Ke. bOand Or pointing device kev presses) to 
the user wierface and all other consistant CASE tool resources, to which thev 
Ea tepOleebD. 1OrkIng tOvevent Mamdlerssmeredy tool level resources navicate 
be sx Slew tesOlurce hierarchy imstead of the user who remains free to alter the 
Cerise Ome aime eves @vnelierda event qucue is polled. Or events are 
nandled as priority interrupts. will be Key efficiency considerations for design): 


° window manager services create and manipulate windows as objects displaved to 
convey information to the user. classes of windows include svstem windows 
iepeate@eocmiiess\ Stemuuser Interiace tool), and tool windows (created by other 
cool resources), either of which may include dialog or alert windows: 


® menu manager allows tool resources to create and display menus consistent with 
the user interface guidelines, and reports menu selections back to the tool 
(inenus allow users to chose options at any time, menu options are imperatives 
used analogously to comumands in more conventional svstems (e.g., print. open) 
SiedltemmativelWe ther may be selections (e@, font size tvpe), user interiace 
guidelines should provide for menu selection via pointing device or command 
kevs. menus snould not be hierarchical (avoidance of modes}): 


‘©Singer (1987) provides an in depth discussion of the user interface philosophy 
and the resources and guidelines required to achieve it. He also covers some 
implenrentation issues and a discussion of the potential of such a user interface for 
significant productivity improvement when fully exploited by advanced CASE tool 
resources such as visual programming tools. 
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e dialog manager used to create and contro! diaiog windows when a tool resource 
must have more information from the user in order to continue a task (dialogs 
are modal if the user must respond before doing anything else, or miodeless if the 
user can still do other things, dialogs mav make use of controls standardized by 
the user interface guidelines and provided by a controls manager, or text entries 
(e.g., maming a file)), the dialog manager can also generate alert windows 
(notes, cautions, warnings) when a potentially dangerous situation arises 
(usually modal)}; 


¢ graphics facilities Which manage the drawing plane in terms of common 
parameters, objects, and functions (e.g., two dimensional coordinate svstem and 
conventions for defining points. objects. rectangles, regions, bit images. bit 
maps, patterns. cursors, graphics pens, icons, transfer modes, drawing 
environments (defining how and where graphics operations will take place). 
Clee) 

e text facilities to perform basic text entry and editing, and handle different text 
chardcteristics (€.9., text font, facegmiede.sizemleadine, etc.) 

(PeatroveloSC someon). 

(2) Data \fode!l Manager. The data model manager would provide for 
manipulation of the chosen environment process data models. The technology exists 
to provide sophisticated filters for converting to and from models supporting various 
processes both internal and external to this environment. 

(3) Udility Manager. In the interest of efficiency and responsiveness. the 
environment service resources should be residentim memory as dre the opericme 
svsteml resources and the user interface tool resource: Lulity service resources (ianaied 
by the uulity manager) and toc! resources im general would most likely be im secomuam: 
storage. The first call to such resources shotila) bring them into memory Until theme 
either sent oack bw the user or, the end of the user session, It should be a charactcriome 
of the environment data model that objects created in the environment are tagged with 
the identity of all environment resources Used in them creation. [he utility mangoes 
snould be called by a resource recorder’ checker function (e.c:.801 the dalqon. 
manager} to locate needed resources and bring them into memory when an ooject 1s 
accessed. “When a required resource cannot ve found the user shouid be told. via a 
dialog. so he can either supply the mussinmge resource. Or proceed in sonic Oten 
direction. Utility resources would include: 

® = text editor 


© text filters, various filters nught be defined to allow data interchange with 
external environments (e.g., via the communications network); 
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® oinding transformers, to allow glueing together parameterized objects with 
different native contexts (e.g., moving a language dependent code package from 
a network library into the abstract, language independent representation of the 
environment data model): 


¢ anv of a number of other possible utilities which have broad applicability 
amiong too. resources and provide a cohesive functional aggregate of svstem 
lever resources (€.g.. a parser or parsers, for the programming languages and 
data mocel supported by the environment, which could be used by a compiler, 
debugger, pretty printer, etic. Or am Umparser to reverse the process). 


b. CASE Tool Resource Layer 

This laver consist of tools which are integrated by their use of the 
ite Ghioenes On ccua. ciseuatn admerence 10 Wiser Interface euidelines, the environment 
Uaioe anc ihe manial and human resources of the environment. I[t is bevond 
the score of this work to complete anv particular portion of the abstract function 
tvping for an environment. At this point our purpose is just to indicate the direction 
Of such an effort. 

(1) Environment User Interface. One might appropriately view the entire 
CASE environment resource hierarchy as a super operating system, with sis resource 
providing functionality simular to the command shell or command line interpreter of a 
Me@vemecimentiona sOperatin® system. ilewever. this resource is the user interface 
guidelines incarnate. and it exploits interactive graphic user interface principles to 
fee celscmuinienummess and enhance productivity. [ft is the example for other tool 
developers who will use the environment service resources and user interface guidelines 
fomecmieve thescommon User interlace aspect for integration of their tool into the 
Sy el ghaetseug 

(2) Project Management Support. This category of resources for the IPP 
environment might include resources to help an individual manage his time. budget, or 
other resources. Objects generated here (e.g., schedules. reports) should be designed to 


facilitate aggregation by the project management support resources of a Project 
Mamaweers environment which 1s created bY extending (bv adding resources to I} the 
IPP environment. IPP tools in this category might include: 

e project scheduier, 


© office quiomeation. 


!"Extensions would likely include security resources (if not already present) to 
control access priviledges to resources objects. 
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(3) System Generation and Management. This should be a familar 
categorv of tools commonly found in programming support environments. These tools 
must assist the programmer in a verifiable transformation of the model of a software 
system, created in the Designers environment, into an executable niodel which must be 
validated against the model created in the Analysis envimonment. Some of these 
resources should nave broad enough applicability to be useful in the Wanagers, 
Analysts, Designers and Maintainers environment. For example, the following are 
necessary to effectively manage ail of the various models (1.¢.) analysis) desi 
implementation, ete) witiia a Sait. dre projec: 

© documentation generator, 

@  =oversion maintane?, 

e archiver, 

© = backup. 
Other tools, in the svstem generation and management category, would include 
programming language specific resources directly supporting transformation of the 
design model into the executable model. One consideration is exploitation) oimen. 
available interactive graphics of the user interface (Singer. 1987) and the power of 
global models of objects (e.g.. construction of objects by selecting templates and setting 
controls or filling out choices in dialogs, manipulation of objects through their displaved 
forms. miultipie simultaneous views, animation, etc.) with tools lke s\ntax 
knowledgeable editors, and interpreting or incremental compiling debuggers. to 
improve productivitv. In other words, use of visual programming techniques. Another 
consideration is exploration of automated transformation technology to take advantage 
cf formal specification technology and calculable verification techniques in order to 
deat directly (with some degree of automation) with the system model generated in the 
Designers environment. For the IPP subset we would begin with the more traditional 
nrogramming support environmnt resources and exploit the user interface for 
productvity gains. Tools would include: 

e syntax knowledgeable editor(s), 

e = =contpiler(s) interpreter(s), me 

© assembler(s). 


eo finker librarian, 


"We prefer the use of an incremental compiler for debugging since it makes 
verification easier than if an interpreter is used during development of source which will 
ater be complica: 
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e 8 deougzers, 
¢ analyzers metrics. 

(4) System Integration and Testing. The IPP user must deal with 
integration of various system modules for which he is responsible. In addition to 
dedugging and verification, he is also concerned with validation of cohesive functional 
Pee OU necS sho ecissist Aleta test scl Generation, regression testing, etc. are 
required and also form a logical base for extension to overall system integration and 


testing. 


C. WHAT ABOUT THE REAL WORLD 

ee es 2oine scisclssuem presented an extremely high level view of CASE 
resource functional abstraction issues in a very limuted scope. Hopefully, the benefit of 
such a discussion {in the context of the current chaotic proliferation of disjoint 
SPepoumestse anid environment resource options) will be the stimulation of well 
directed top down efforts to bring order to the devlopment of CASE environments 
Gir@uemeueamtechniques. ie will conclude with a brief discussion of the major 
Cu tteteomron tie success Of sucti efforts, directions for continuing this work. and 


feCeomavenidations [or \ISB. 


VI eONCLUSIONS 


A. INVITATION FOR REVOLUTION 


“Welcome to the CASE revolution,” proclaimed the ebullient keynote speaker at 
a recent symposium covering computer-aided software engineering (CSE). 
While well meant, those words may not have been well chosen fora technics 
audience ever watchiul of marketing hype and still reeling from the past 
‘revolutions’ of fourth generation languages. relational data bases. structure 

progranuning and real-time systems. ...the thought of going through vet another 
revolution is less than appealing tO mOStm. . .appedling abouP@ASte. cis that its 
cools. . .do not reaily represent revolution but rather evolution of tools and 
concepts. . .already: embraced in the systems develooment ec, ele.) Ehulimes) 2s 
eS) 


be 


lVebster $ (1 96G memo, jodetines Gecolutioneds .tadical.and complete chance, jams 
We would agree that the CASE concepr is evolutionary, not revolutionary. In this 
thesis we've acknowledged the sofmvare problem, and studied the evolution of software 
engineering towards solving it. We have littl doubt that GASE environments aircms 
niturai and needed stage in this evolution. Probably the most compelling €videnceuam 
his is the huge demand for. and resuitant proliferation of, disjoint CASE tooisuama 
[rae sae eM nenimeliis: 

Weve coalesced, from a variety of sources, spanning several vears, a conscnaa. 
of fundamental principles for good environments. We've reported on, the general siate 
oi technology which fails to adhere to these principles, and the technology and market 
‘actors which have encouraged such unprincipled bottom up developments. 

We've reported on promising research, at the Naval Postgraduate School. 
invo.iving formal specification of functional (physical and problem solving) resources 
(abstract function typing). Weve proposed a top down strategy for developing 
integrated CASE environments in an open, extensible, evolutionary manner which 
could achieve standardization through functional interfaces allowing integration (ooth 
common user interface and interoperability) without conflict over advances in harcware 
and software technology, and supporting multiple processes, models, programnung 
lanGuaees, che. LarOlgia ils Extensioniin. 

We've discussed the major obsiacles to sU¢h a Sitatecs ine "task {1S Gilliemn 


because the imperatives include words like agree and the descriptors are words like 
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standard. And, agreement on standards imiplies a required shift in marketing strategies. 
especially for those hardware and software houses whose symbiotic relationship is the 
basis for their competitive edge in controlling their market share. Our strategy 
provides for competition in hardware and software technologies directed noi cnlv 
towards inplementing standard functional resources, but also towards defining and 
Implementing new functional resource abstractions which will be integrated with earlier 
resources. While this would still allow for substantial competitive arenas, they would 
be diferent than the current arenas. This would be a “radical and complete change”. 
So, 1 may be argued that our strategy is an invitation for revolution. 

Revolutions tend to begin with a small group of protagonists Who mus: gather a 
following convinced that their cause is just and that revoitition is necessary. One goal 
of tnis particular revolution is relief from the current environment chaos and the dawn 
Cierew ave Ci Open, extensiole, integrated environments built from portable. reusable 
functional resources. Another goal is focusing competitive innovation on advancing 
the state of technology without getting bogged down just trving to cope with the chaos 
Spawned along the way. _ 

Re melieve ine only practicalmicamsectmimaming such a revolution is to make it 
seem I:ke evolution. In our discussion of standards enforcement vs. encouragement, we 
favored encouragement of standards through good design, availubility, and social cnange 
(realization that the standard is a standard of necessity). Social change concerning this 
issue 1s alreadv afoot with more and more work focusing on abstraction, rigorous 
POEDia smieliser IMiemace Cesicn and va@biect oriented soitware engineering. This is a 
Pec sia eowecess, but it may be accelerated with a catalyst in tne form of 


availability of well designed resources. Future work should be directed towards that end. 


B. FUTURE WORK 

Functional analysis is probably the hardest part of the task. Weve discussed a 
combination top down botton: up proccess, of balancing high level requirements 
against physical resource constraints, in order to arrive at an abstract ‘unction 
hierarhy to meet the requirements. The really difficult thing is to do this without 
letting perceived (but not actual) constraints, derived from the way things are done 


today (implementations), jaundice the functional abstractions. To arrive at useful 


For example, the chaotic proliferation of programming languages. by the early 
1S7O’s, so saturated development rescurces and hampered development of new 
technology that development of anything more than rucimentary programming support 
cools (compilers assemblers. linkers and loaders) was considerably delayed. 


ay 


abstractions, Work should progress in the context of a real world environment (keeping 
in mind the ultimate goal of portable resources). Detailed process and requirements 
analvsis, and understanding. are prerequisites to the high level balancing act required in 
functional analvsis. Working in the real world (e.g., the foundations, say an IPP 
subset, of a CASE environment for an organization like M{SB) demands practical 
results vs. esoieric discourse. Practical results are the essence Of catalsts foros = 
change. 

Once a minimal functional resource hierarchy is available. abstract resources 
must be formally specified. Then, parallel éfiorts can be applied to implemeniadem 
Completed impiementation of the resources will constitute a prototype version of a 
CASE [PP environment. Several prototypes should be constructed from) themsand 
formal specifications, and testing should be designed to evaluate achievement of the 
principles for a good CASE environment. By repeating the process from functional 
analvsis through prototype. functional evolution should add CASE resources for direct 


support of increasing portions of the software engineering lifecvcle. 


C. RECOMMENDATIONS FOR MSB 

Depending on the resources available for such an undertaking, the make process 
described above could take several vears (not to mention the time required to win the 
market revolution and see conimerciallv available resources for constructing working 
integrated CASE environments). Weve also said that MSB lacks the résourcesmis 
undertake such a project. Other, more practical Solutions are of immediate concern 16 
ESI 

i. Near Term 

Given insufficient resources to make their oWmMG@ASEeenvironment. aqdeaie 

inherent disadvantages of the available buy options, we decided to consider some sort 
of nvbrid, of the available alternatives. as a potential means of means of acquiring 


CASE resources while achieving at least some of the advantages embodied tn the 


-"Encouragement of such development using resources which represent DoD 
sunk costs (e.g., Naval Postgraduate School (NPS) Master's Candidates) and are 
essentially free to MSB has the potential to contribute to the revolutionary efiort in the 
long run, but is not likely to offer practical CASE environment solutions in the near 
term. Bottom up NPS work on specific tool resources (not incorporated to date under 
a top down CASE environment development plan) like AdaMeasure can offer limited, 
more immediate, practical benefits to \{SB (while also contributing to their existing 
disjoint environinent). 
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genera: principies for a good environment. We've devoted considerable thought io 
hvbrid make buy schemes, and quite frankly there aren’t many good choices. 7! 
de Physical Resources 

(l) Hardware. We believe that committment to unique architectures and 
a proprictarily constrained source of software is a nustake both now and for the future. 
Picxibiuity now, end portability and reusability in the future. are best served bv a 
powerful general purpose hardware suite. \NISB has already defined reascnable 
runimum physical hardware constraints (Missile Software Branch, 1986, p. $}. At the 
Pi] Waese COnsitdints seemied to dictate Glaesusc of relatively hign priced (S25K - S75kK) 
32-bit professional Workstauons. Recent market releases of networkable 32-bit personal 
comiputer Workstations, rival the niore expensive machines in capability and are driving 
Peeseier6nd (41 more allordablesranceagaehees25h). Such an affordable general 
Bee co mio rateease SeCISeiousbe a reasonable first step to productivity 
improvement, with the capability to host CASE resources available today and into the 
(ues 

(2) Operaiing System Resources. We've already discussed the problems 
inherent to Standardizing on top of an existing operating svstem. A traditional 
operating system choice is likely to be made based on such considerations as: 


ee ieee ide tle mest cxpemence withmeliat do we use now? (in the case 
See ivoreterincver would likely be UNIX}: 


¢ ts our current operating svstem adequate? 
e What additional capabilities (1.e.. graphics, database) are required? 


e Which operating svstem promises to support tne broadest selection of off-the- 
sheif tools ti.e., a defacto standard)? 


Ame so ony wre lave little to offer here other than this common sense sort of approach 
to trv to ensure the operating system will be adequate and supported until something 
Sigmar) soctrer comes along. Obviousl, i UNIX were kept as a defacto standar 


operating svstem, a graphics capability would be required (probably best to stick wih 


a 


the ISO GKS standard). Since many of the disjoint off-the-shelf CASE resources to be 
hosted employ their own database managemient, a choice on a database munagement 
cvsteml, to augment the UNIX file system. might either be a non-requiremeni or be 


dictated bv the tool resources chosen. 


-'One short term option. which we won't discuss, is to concentrate on manual 
rescurces and simply wait on better options from CASE development efforts. 
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b. Problem Solving Resources 

So far this near term discussion has sounded like straight short term off-the- 
shelf buy. Environment service resources are the level at which we can see practical 
potential for compromise between the short term off-the-shelf buy and some portions 
of the make option. But, look ahead for a moment at the disjoint tools to be bought. 
The tools of the most interest are likely to be the new CASE tools, offering relatively 
complete, language independent, support to the early software engineering phases of 
structured analysis, structured design, and im some Cases €Ven ceneration Of Somme 
code. (You supply the compile, debug and test functions.) These tools in general have 
unique internal interfaces for imteroperability” |ney secnerally save ssomii 
unprincipled, inconsistent, and highly modal user interfaces which are also unique. 
These tools generally do not consistently adhere to event driven control vs. hierarchical 
modalitv. They generally support a limited set of structured methodologies. The point 
were getting at is that there 1s little common ground on which to base Gavironmen: 
service resources. The internal interfaces of these various tools are generally so deeply 
involved in their design that it is doubtful any monetary incentive (especially something 
MISB could offer) would entice a developer to re-encineer his tool to intcractsemm 
through MSB standard data models of objects. That leaves the user interface. 

Would it be possible for MSB to develop standard user interface guidelines 
based on availabuity of some suitable service package (say GEM, assuming it 1s 
supported by the operating svstem of choice) and then successfully get CASE tool 
developers (for the tools MSB reallv wants) to host their tool on the service package 
vith a user interface conforming to the MSB guidelines? Although probably less 
difficult than the common data model problem, the answer 1s still probably no. The 
task would not be trivial. -~ and with a market of at most 18 users, a prohibitive 
oricetag should be expected. 

One other possibility, which falls somewhere between the long term and 
short term off-the-shelf buy option, would be to identify a general purpose computing 
svsiem meeting the minimum hardware constraints, for which an operating system 
supporting a widely accepted {defacto standard) well principled. event driven, user 
friendly interactive graphic user interface, already exists. While: the womeinal opie 


Macintosh fell short of the minimum hardware constraints, the 68020 based Macintosh 


We, ~ : : c . Cc 

--For example, few existing tools are implemented using event driven program 
control. so major restructuring would be required to achieve user interface guidelines 
based on event driven responsivness and permissiveness. 


oe 


Il, scheduled for release this summer. will come much closer. The Macintosh user 
interiace guidelines and service resources ure well principled and accepted. Originally 
targeted at a market of unsophisticated computer users, the Macintosh still suffers 
Oe Je cas ime aS a [anc) te. f1OMwever, it is in fact a powerful system in its own 
Menem Over saiGh sUserse iver, 11 presents a lucrative horizontal market to the 
soltware developers. Off-the-shelf software is plentiful and the user interface has 
Survived tO become a defacto siandard fer Macintosh application developers, while also 
influencing the competition. Among the off-the-shelf Macintosh software are, 
sophisticated svntax know.edseable editor, visual programming incremental compute 
and debug packages, at bargain basement prices (thanks to the horizontal market). 
icwes ws McINtOsia Ohen architectures @romise access to UNIX and \{S-DOS. The 
De fiche (Sundial (east 10 he User interlace chaos, theresare alternatives. But, it 
oe moOeeom Ti iciie ol (le part Olethe Customer, tO not accent deviation from 
Poet eC uUscm Mier. cce 2Uidclines md, Suideline admerence can be a reality if vou 
Oyen opens ie 1001S Fequired to miake adherence casier than reinventing the wheel. 
There is, of course, alwavs a bottom line. In this particular discussion it goes like this. 
Pee ee eesh  incrignally) ie, disregard the Kluge user interface) off-the-shell CASE 
COOisea atlabic for Niacintosh’ What about Ada support? The answers are genera:ly 
(oe ea loi dione oct a developer tO port iis product to Macintosh (adhering to 
fee eee teridce) er tOOabi Mot, BUL Ine incentive ought to be greater due to a 
Bevemlchy larger Market. 
Saget te Oo10im ine Ol Lae whole medr termi issue Would seem ‘to be. if tts 
@eortlcer Of SULYivaleioin the competition and buy up the disjoint tools of vour choice. 
-. The Future 
Peedi ihm COmuliced that the future of CASE environment devclopment 
lies along the path we've proposed for functional abstraction and formal specification 
of phvsical and problem solving resources. Key to this effort are standardization on 
user interfaces, and interoperability based on manipulation of global ohbrecis. 
Consistency checking, validation. verification, and testing must also be founded on the 
odiects themselves and their interrelationships. Efforts hike CAIS within the DoD seem 
[oO have a start on this path in an extremely limited and language specific wav, and sans 
rigorcus formalism. But, they are a start, and enjoy direct support from a much ligher 
level «within not only the DoD bureaucracy, but (due to clout) within the industry as a 


whole. If MISB wants better choices in the future, we recommend they aggressively 


lobby the DoD infrastructure to expand work like CAIS in th 
proposed. 


1e direction we've 
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